Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (hermes.apache.org: domain of vreddyp@gmail.com designates
 64.233.170.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=gUcoK5X+ETW9YCHM/ZaK7zIbv8N+aPqcUB0Z79dOCGqL8h85DPX11a7ATrdTC1a7K3pdnxGm8t7iTQ4TZiKg5PVGhWhgS9fAScIE8AAUDQAJgYMvXLip0Ua/3xEeu9uH+/wir+Ho6eNrRRfM7eivrBYuSP8zn6tZHobO214LIJc=
Message-ID: <fadf66310505170012284f8277@mail.gmail.com>
Date: Tue, 17 May 2005 12:42:44 +0530
From: Venkat Reddy <vreddyp@gmail.com>
Reply-To: Venkat Reddy <vreddyp@gmail.com>
To: axis-dev@ws.apache.org, Ruchith Fernando <ruchith.fernando@gmail.com>
Subject: Re: [Axis2] Proposal - DOM Implementation for Axis2
Cc: dims@apache.org
In-Reply-To: <559c463d05051612227a594698@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <559c463d05051603201b3d4a4c@mail.gmail.com>
	 <19e0530f05051607235349db01@mail.gmail.com>
	 <559c463d05051612227a594698@mail.gmail.com>

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 <ruchith.fernando@gmail.com> wrote:
> Hi Dims,
>=20
> 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).
>=20
> 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.
>=20
> 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 :-)
>=20
> Thanks,
> Ruchith
>=20
>=20
> 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 take=
s over:
> > >
> > > Since the security handlers depend on the DOM interfaces, they  canno=
t
> > > 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 =3D 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 =3D new StAXSOAPModelBuilder(pp, new DOM=
Factory())
> > >
> > > 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 wil=
l
> > > set the reference to the new DOMSOAPEnvelopeImpl
> > >
> > > Therefore to achieve this we need to have remember the following poin=
t
> > > 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/
> >
>