axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: Request for XML Filter (AXIS2-1085)
Date Tue, 24 Oct 2006 23:50:00 GMT
On Tue, 2006-10-24 at 12:15 -0500, R J Scheuerle Jr wrote:
> 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.

These two statements are not consistent: if its a StAX filter its a StAX
filter - there's no message context involved. If you want the MC then
the right solution is a handler.

> 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).

Again that doesn't make sense to me - if you want to filter at the OM
level that's essentially what a handler is. If you want to filter at the
StAX level I can certainly see it has some value but I'm not convinced
its of much general value .. the practicalities are going to be very
hard to just remove some information items at the StAX level.

> 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.

If you remove the headers that are not processed at the node then they
will not be propagated to other nodes; that's incorrect behavior for an
intermediary.

In any case, that's what handlers are for. 

> 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.

?? Again that seems very fishy to me- you're going to examine each and
every element that's going thru to identify the one element you care
about. That means you'll slow everything down .. I don't see how
navigating the OM tree will be slower in general.

Sanjiva.



---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message