And We also inspect another solution which uses XMLInputFactory.

In this solution, Filter is inserted at XMLInputFactory which is written by us.
The XMLInputFactory returns Filter instance. The filter wraps XMLStreamReader
(Filter -> XMLStreamReader). And the filter goes into builder (StAXBuilder ->
Filter -> XMLStreamReader). Here, filter configuration is stored in XMLInputFactory.

We expect that the ode which pass MessageContext to XMLInputFactory will be too complex,
because XMLInputFactory is wrapped by StAXUtils and StaxUtils reuses several XMLInputFactory.
To avoid this complex, we can use ThreadLocal-Storage. We store MessageContext immediately to the
ThreadLocal-Storage when it is created, then filter which is in the same thread can get
MessageContext by the ThreadLocal-Storage. (In current implementation, MessageContext is stored
on ThreadLocal-Storage at receiver layer. That is, MessageContext is not stored when the message
processed in transport layer and handler layer. To archieve this XMLInputFactory solution,
we have to change transport layer to store MC to TLS.)

# We do not think this solution is good. because TLS is used.

The points of XMLInputFactory solution are
    - Insert filter inside of XMLInputFactory
    - Filter configuration is stored in the XMLInputFactory
    - Pass MessageContext by using ThreadLocal-Storage
   
    pros) There are no filter related code in AXIS2.
    cons) Need to change to AXIS2 transport layer component to store MessageContext on ThreadLocal-Storage when it is created.
    cons) This seems contradict to MC design. We put context information in Axis Service/Operation/Message context because there is no control of when there is a thread switch.

Regards,
---------------------------
Takahide Nogayama

Reply via email to