axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] Proposal - DOM Implementation for Axis2
Date Mon, 16 May 2005 18:22:56 GMT
hi,

doesn't it mean that XML will be parsed twice or events replayed 
(PullParser pp = messageContext.getSOAPEnvelope().getPullParser())  and 
original OM tree that was first built is then discarded (first built by 
StAXSOAPModelBuilder but without DOM then again by StAXSOAPModelBuilder 
but with DOM)?

i think there is a better solution: if it is detected that that one of 
modules/handlers requires DOM (described in its metadtaa) then why not 
to use builder/factory that will produce OM classes that implement DOM 
interfaces from beginning?

alek


Ruchith Fernando wrote:

>Hi All,
>
>In implementing WS-Security capabilities on Axis 2.0 we will have to
>convert the OM to DOM and provide the complete SOAPEnvelope as a DOM
>implementation.
>The following changes and additions are proposed to the OM
>implementation to support this.
>
>1.) The org.w3c.dom.* interfaces will be implemented extending the OM
>Impls. (org.apache.axis.dom.*)
>Also there will be an implementation of org.apache.axis.soap.*
>interfaces extending from the DOMImpls. (org.apache.axis.dom.soap.*)
>In this situation we will have to change some of the method names in
>the OM interfaces. E.g.: getNextSibling, getPreviousSibling in OMNode
>
>2.) A DOMSOAPFactory implementing the SOAPFactory will be introduced
>to provide the DOM_SOAP impls. to the StAXSOAPModelBuilder
>
>3.) How to switch the builder when the security related handlers takes over:
>
>Since the security handlers depend on the DOM interfaces, they  cannot
>work with pure OM instances. They expect DOM impls. So now there's a
>need to switch from normal OM factory to DOM factory. Therefore
>following method is proposed to to handle this.
>
>There will be some processing of the SOAPEnvelope before it reaches
>the security handlers.
>And there will be a reference to this partially built SOAPEnvelope in
>the MessageContext object. This SOAPEnvelope consists only of pure OM
>based elements (org.apache.axis.soap.*). Now we get the pull parser
>from the SOAPEvelope we have through the OMStAXWrapper (This is used
>to get the pull events from OMElements, irrespectiveof their build
>state)
>
>PullParser pp = messageContext.getSOAPEnvelope().getPullParser()
>//Returns a pp pointing to the start of the document
>
>Then we create a new StAXSOAPModelBuilder passing the DOMSOAPFactory
>together with the pull parser returned from the SOAPEnvelope.
>
>StAXSOAPModelBuilder builder = new StAXSOAPModelBuilder(pp, new DOMFactory())
>
>At this point the SOAPEnvelope reference in the message context is
>pointing to the older pure OM based SOAPEnvelope.
>This will have to reassigned to the new OM+DOM based SOAPEnvelope, as 
>shown below:
>
>messageContext.setEnvelope(builder.getDocumentElement()); // This will
>set the reference to the new DOMSOAPEnvelopeImpl
>
>Therefore to achieve this we need to have remember the following point
>as a best practise : DON'T POINT TO THE SOAP ENVELOPE OF A MESSAGE,
>JUST POINT TO THE MESSAGE_CONTEXT ONLY.
>
>I think this is one of the best use cases which shows the beauty of
>the Factory and Builder concept used in Axis2 - OM design :)
>
>Thanks,
>Ruchith
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message