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,
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)
![Inactive hide details for Sanjiva Weerawarana <[EMAIL PROTECTED]>](gifA4qA0yIl67.gif){kind=small}
Sanjiva Weerawarana <[EMAIL PROTECTED]>
10/24/2006 06:50 PM
|
|
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]
