[ 
http://issues.apache.org/jira/browse/WSCOMMONS-76?page=comments#action_12434318 
] 
            
Eran Chinthaka commented on WSCOMMONS-76:
-----------------------------------------

I agree with the idea here. But I'm in doubt whether this should be tightly 
intergrated to Axiom builders or not. In other words should this be supported 
as a first class thing?

1. Axiom builder APIs were in Axiom for some years and there weren't a single 
suggestion to make changes to them. And it was/is one of the APIs which users 
always have to use. When I introduced the SOAPVersion param to the 
StAXSOAPModelBuilder constructor, people were not happy. Now we are trying to 
add another param, context, which will not be used 99.9% of the time by the 
user. (but yes we are still slowly improving apis like OMElement)

2. This can be easily implemented external to the builder. Create filter from 
the mechanism you've suggested and get a parser instance from it, pass that to 
the builder. Whatever you do internally, do it externally and provide 
documentation.

3. I saw you've added setParser() method to the builder, which we purposely 
avoided. If some one tries to change the parser, while the object model is 
being built or partially build, everything will get screwed. Please do note 
that this method was not put in, purposely.

> StAX Filter [ Data conversion, extraction, or do something between 
> XMLStreamReader and StAXBuilder]
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-76
>                 URL: http://issues.apache.org/jira/browse/WSCOMMONS-76
>             Project: WS-Commons
>          Issue Type: New Feature
>          Components: AXIOM
>         Environment: windows
>            Reporter: Takahide Nogayama
>         Attachments: patchAXIOM_to_moduleaxiom-apisrcmainjava.txt, 
> patchAXIS2_to_moduleskernelsrc.txt, src_demo.zip, StAX_filter_architecture.ppt
>
>
> Filter is interface and extends XMLStreamReader. Filter wraps 
> XMLStreamReader. And XMLStreamReader of StAXBuilder is replaced by Filter.
> In building phase, next() method must be invoked on each event. filter get 
> result of next() from XMLStreamReader, and do some process, then return the 
> result to StAXBuilder.
> We can set Object on filter. Filter get some information from it and set 
> result on it to transfer the result.
> We can set StAXBuilder on filter. Filter get OMDocument from the builder. If 
> filter want to know past information, the OMDocument has it.
> If StAXBuilder has lastNode() method, Filter can make reference list to 
> OMNode. this is commneted in 
> http://issues.apache.org/jira/browse/WSCOMMONS-75 .
> Example1)
> SOAP header has some child elements. and they has actor Attribute. it 
> indicates which intermediary should process the element.
> ExtractMyActorSOAPHeaderFilter.java is implementation of Filter for this 
> example. The filter monitors locaName at first,
> If START_ELEMENT whose actor does not equals myactor is found, The filter 
> invokes next() until the element's END_ELEMENT.
> Thus, The soap header elements which has other's actor are not transfered to 
> StAXBuilder. We can ommit creating fruitness OM.
> Example2)
> If StAXBuilder has lastNode() method, Filter can make reference list. The 
> list has OMNode whose actor indicates myactor.
> After building, If we want to access Security header elements which has 
> myactor, we can access the element directry by using the reference list.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to