Mailing-List: contact dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ws.apache.org
Received-SPF: pass (nike.apache.org: domain of andreas.veithen@gmail.com
 designates 209.85.216.42 as permitted sender)
Received-SPF: pass (google.com: domain of andreas.veithen@gmail.com designates
 10.224.177.145 as permitted sender) client-ip=10.224.177.145;
MIME-Version: 1.0
In-Reply-To: 
 <CADg9GQZyX3dUFf+G0ED08hjsuxVMrTYViJ0ZE5uAjWCZEhr2fA@mail.gmail.com>
References: 
 <CADg9GQZyX3dUFf+G0ED08hjsuxVMrTYViJ0ZE5uAjWCZEhr2fA@mail.gmail.com>
From: Andreas Veithen <andreas.veithen@gmail.com>
Date: Mon, 27 Feb 2012 21:44:05 +0100
Message-ID: 
 <CADx4_uULDm=CevuAXdCQEVZJ98Ah_LrLawkQos8UzHaSvyp9tQ@mail.gmail.com>
Subject: Re: Axiom looses information when a child element is re-added to its
 parent using #addChild
To: dev@ws.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Should be fixed now (see AXIOM-411). Thanks for reporting this issue.

Andreas

On Thu, Feb 23, 2012 at 15:26, Kasun Gajasinghe <kasunbg@gmail.com> wrote:
> Hi,
>
> I've using Axiom for some work, and I've faced this issue that I think is=
 a
> bug in Axiom. The issue occurs when a given OMElement is re-added to its
> parent using parentOMElement#addChild method. In that case, the said pare=
nt
> loses references to all the children after the child OMElement.
>
> To make it clear consider the sample xml doc [1]. Now, say you retrieved =
the
> operation named "Sandesha2OperationInOnly", by xpath or any other means.
> Then, you re add it to the parent <service>. After that, service loose
> references to siblings after the said retrieved element (ie. <binding> an=
d
> <parameter>). I've provided a sample code for this which I've simplified =
to
> not use xpath for better understanding. [2]
>
> Yes, I can do a validation on whether I'm adding a child to the same pare=
nt,
> but why? This should be handled at Axiom level. The example was a much
> simplified version; I've spent hours wondering how I lost all those
> information, and found that a seemingly innocent method invocation was th=
e
> cause! :) Can anyone reproduce this? I'd like to provide a patch for this=
.
>
> [1]
> <service name=3D"HelloService">
> =A0 =A0 <operation name=3D"Sandesha2OperationOutIn"/>
> =A0 =A0 <operation name=3D"Sandesha2OperationInOnly"/>
> =A0 =A0 <binding name=3D"HelloServiceSoap12Binding">
> =A0 =A0 =A0 =A0 <operation name=3D"greet"/>
> =A0 =A0 </binding>
> =A0 =A0 <parameter name=3D"name1">val1</parameter>
> </service>
>
> [2]
> OMElement documentEle =3D new
> StAXOMBuilder("resources/services-op-test.xml").getDocumentElement();
>
> // Now retrieve=A0<operation name=3D"Sandesha2OperationInOnly" />
> OMElement opElement2 =3D (OMElement)
> documentEle.getFirstElement().getNextOMSibling().getNextOMSibling();
> //OMElement opElement2 =3D new
> AXIOMXPath("/service/operation[@name=3D\"Sandesha2OperationInOnly\"]").se=
lectSingleNode(documentEle);
>
> documentEle.addChild(opElement2);
>
>
> --
> ~~~*******'''''''''''''*******~~~
> Kasun Gajasinghe
> Software Engineer; WSO2 Inc.;=A0http://wso2.com,
> linked-in:=A0http://lk.linkedin.com/in/gajasinghe
> blog:=A0http://blog.kasunbg.org
>
>
> twitter:=A0http://twitter.com/kasunbg
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org