No problem. We are also completing SOAPDocumentImpl anyway. - venkat
On 5/17/05, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > HI Venkat, > > WSS4J impl and especially XML-Security impl are based on DOM. > > For example there are a instances in both impls where the DOM Document > object is used to create elements using the createElement and > createElementNS methods. IMHO we cannot change this behaviour and > expect XML-Sec and to work on SOAPHeader and SOAPBody. > Also the core of WSS4J org.apache.ws.security.* stuff uses only DOM. > > Therefore I guess we will have make sure SOAPDocumentImpl provides > those methods, so we can use XML-Sec and WSS4J without a problem :-), > What do u think? > > Best regards, > Ruchith > > On 5/17/05, Venkat Reddy <[EMAIL PROTECTED]> wrote: > > Ruchith, > > > > We should be able to use the SAAJ implementation for DOM support. I > > dont think we need a separate set of classes to implement DOM. Ashu > > and Jaya are completing the implemntation for SAAJ and test cases. > > > > SOAPDocumentImpl is provided as part of implementing SOAPPart for > > attachements. I'm not sure you will need it for dealing with the > > children inside a header or body. For example, you should be able to > > access and manipulate the children inside a SOAPHeader or SOAPBody, > > using just the SAAJ API, without the need to go for SOAPDocumentImpl. > > > > -- venkat > > > > > > On 5/17/05, Ruchith Fernando <[EMAIL PROTECTED]> wrote: > > > Hi Dims, > > > > > > I think the SAAJ implementation can be used once we finalize the > > > implementation of few places such as > > > org.apache.axis.saaj.SOAPDocumentImpl (creation of the new DOM > > > Elements is missing in here). > > > > > > As long as the OM structure is preserved for the following handlers to > > > work on (e.g: after security), there will be no problems at all. > > > > > > With the proposed solution I think we can get away from having two > > > object strctures (OM and DOM) at the same time. But I think I can try > > > to go ahead with what is there is in SAAJ impl without much of a > > > problem :-) > > > > > > Thanks, > > > Ruchith > > > > > > > > > On 5/16/05, Davanum Srinivas <[EMAIL PROTECTED]> wrote: > > > > Ruchith, > > > > > > > > Did you consider using the SAAJ stuff which already has dom interfaces? > > > > > > > > -- dims > > > > > > > > On 5/16/05, Ruchith Fernando <[EMAIL PROTECTED]> 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 > > > > > > > > > > > > > -- > > > > Davanum Srinivas - http://webservices.apache.org/~dims/ > > > > > > > > > >
