> > 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?
Yeah, this is the nice picture we like to see, which may not be the actual picture. We create the builder within the transport. So do u want to expect the transport to find the correct builder and assign ? And take this example. We know that there is a service in our Axis Server, which security is optional. Meaning messages may come with or without encrypted. So when a message comes to the service how can the transport know, whether the message is encrypted or not. If he knows that, yes we have the nice cute picture u mentioned ;). So that's the reason behind us treating the message as a usual one initially, and if the domain specific handler, like wsse handler, detects what to do he can follow the proposal put forward by Ruchith. Regards, Chinthaka > > 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 >
