axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <chinth...@opensource.lk>
Subject Re: [Axis2] Proposal - DOM Implementation for Axis2
Date Thu, 19 May 2005 02:38:09 GMT


Hi Venkat and all,

Please find my comments below.

> 
> 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.

I agree that you guys are doing a tremendous and highly appreciable amount
of work by implementing/completing DOM impl and the SAAJ impl.

But the proposal gives another improved way of implementing the same thing.
Again, I agree that we need a separate set of classes for this, but I think
we can use the work you have done so far to ease this task.

-- Chinthaka

> 
> 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 <ruchith.fernando@gmail.com> 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 <davanum@gmail.com> wrote:
> > > Ruchith,
> > >
> > > Did you consider using the SAAJ stuff which already has dom
> interfaces?
> > >
> > > -- dims
> > >
> > > On 5/16/05, Ruchith Fernando <ruchith.fernando@gmail.com> 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/
> > >
> >
> 




Mime
View raw message