Request for XML Filter (AXIS2-1085)

[R J Scheuerle Jr]

Comments from Eran in AXIS-1085:
<eran>
Hi all,

Sorry I'm bit busy with Axis2 1.1 so my responses on this issue might be late.

I agree with you about the change we did in Axiom to introduce your FilterAware thingy. But I cannot understand what you are trying to do inside Axis2 with it.

In your explanation, you have mentioed that Filters can be used to hide un-necessary elements to intermediaries by not presenting them to StAXBuilder. What I can not understand is, if you supress them, then how can the intermediary send the message to other nodes. Every node has to build the OM tree, to the extent that they need information, and that building should be continuous. But if you introduce filters some parts are lost and when the intermediary is gonna send, those parts are missing in the out message.

1. Can we please move this thread to axis-dev, as it is much convenient there to talk about this?
2. If possible. please explain your reason behind putting this code "inside Axis2"?
3. Can we not commit any of these changes/patches to Axis2 until we are settled with the decision? Takahide can add patches for us to understand the concept, reading the code, but please let's not commit. It is just a suggestion from me.
</eran>

<scheu>
Here are my answers to the above.

Takahide, please correct me if I am wrong.

Takahide would like a plugin, which he calls a Filter, which satisfies the following requirements.
A) A Filter wraps an input XMLStreamReader and implements an XMLStreamReader. The Filter intercepts each StAX event and can propogate the event.

B) A Filter has access to the Axis 2 MessageContext.

C) A Filter may have access to the Builder so that it can access the OM tree. (This was the BuilderAwareReader code that was
added to Axiom as part of WSCOMMONS-76).

Usages of a Filter:
USAGE 1) If this SOAP node is the Ultimate SOAPReceiver, a user provided Filter could remove SOAP Headers that will not be processed by the node.
Filtering the headers could increase performance and reduce the memory usage.

USAGE 2) If a QOS handler requires access to certain om nodes, the QOS provider could provide a Filter that caches the location of these nodes as the events are streamed. The end result is that the QOS handler has direct access to the nodes without doing a costly traversal.

USAGE *) Takahide would you like to describe some additional usages ?

Answer to Question 1) Agreed

Answer to Question 2) The Filter interface and configuration needs to be part of Axis 2 because this is where the XMLStreamReader gets connected to the OM Builder. This is the point where the Filter (if configured) needs to be inserted. We agree that the actual Filters are provided by users/qos providers and are not part of Axis 2. (It is possible that Axis could provide some default filters..ie. a logging filter for servicability..but that is not the intention of this contribution.)

Answer to Question 3) Agreed

</scheu>

Rich Scheuerle
IBM Web Services
Apache Axis2 ([EMAIL PROTECTED])
512-838-5115 (IBM TL 678-5115)