R J Scheuerle Jr/Austin/[EMAIL PROTECTED] wrote on 10/25/2006 07:39:03 AM: > 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. > <noga> I agree about using handler as primary processor. Filter helps > the handler by doing some process instead of handler. There are some > processes which is processed more efficiently on StAXEvent than on OM > tree. Filter will cooperate with handler. So messageContext is need to > transfer the results of filter's processing to handler. </noga> > > > 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. > <noga> If we winnow or convert some OM element, some attribute value or > some test value at the OM level, we have to create the OM element which > will be removed or converted soon. Remove scenario of Filter aims to > winnow without creating such OM elements. </noga> > > > 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. > <noga> I think so too, this example is not good for intermediary</noga> > > > 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. > <noga> If we want to get only one element by using filter, To avoid > to examne against all element, iFilter shuold disable itself when > the first target is found. But this scenario is not realistic,
One of the possible use cases for filter is for checking uniqness of a piece of data, if this is implemented in using filter, the check and enforcement can be done during the parsing of the message. This will save the walking of the OM tree again. > > For example, "Id" attribute can be set on any elements. and it is > usually used to refer the target element. When we want to get the > OM element which has the id at handler layer, we can not know where > the OM element locates in the OM tree. we have to traverse the tree > to find the element. > we can make map which returns OM element corresponding specified "Id" > value on filter layer by using this pick up filter. Then we can access > to the element directly. I think this is efficient and realistic scenario </noga> > > > Rich Scheuerle > IBM Web Services > Apache Axis2 ([EMAIL PROTECTED]) > 512-838-5115 (IBM TL 678-5115) > [image removed] Sanjiva Weerawarana <[EMAIL PROTECTED]> > > > Sanjiva Weerawarana <[EMAIL PROTECTED]> > 10/24/2006 06:50 PM > > Please respond to > [email protected] > > [image removed] > To > > [image removed] > [email protected] > > [image removed] > cc > > [image removed] > > [image removed] > Subject > > [image removed] > Re: Request for XML Filter (AXIS2-1085) > > [image removed] > > [image removed] > > > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > [image removed] Thanks, Henry --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
