You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Deepak Bhole <db...@redhat.com> on 2006/02/09 23:19:15 UTC

setText() adding duplicates to OMElement?

Hi,

I have come across an interesting (bug?) in Axiom. As I am still new to
Axis, I wanted to know others thoughts before I went around making
patches in critical components, as it may have far reaching consequences
that I am not aware of yet.

I enabled REST support and in an attempt to trace code paths, I set up a
simple example with the "echo" service. The payload sent to the server
contains a <Text>sdf</Text> element, and the server is expected to
change this to <Text>Changed by service</Text>.

I noticed that the payload sent was correct, but what the server sent
back was <Text>sdfChanged by service</Text>. So I checked it out to see
why that "sdf" was still there. Here is what is happening:

HTTPTransportUtils.createEnvelopeFromGetRequest() calls
omEle.setText(value)

omEle is an OMElement. In OMElement.setText(), there is the line:

this.addChild(OMAbstractFactory.getOMFactory().createText(this, text));

This is causing a duplicate entry because OMFactory.createText() creates
an OMTextImpl (which extends OMNodeImpl), and OMNodeImpl's constructor
has a call to addChild() on the parent.

Thus, in short, setText() calls createText() which causes the text
element to be added as a child to the parent, and then further down,
setText() calls addChild() explicitly, causing the text child to be
added again. This is why that "sdf" was showing up in the response
message, because only the first "sdf" node was being removed when I
called setText() on server side.

I was thinking of removing the explicit addChild() call in setText().
This seems to be a workable solution with no side-effects. Does anyone
who knows the code better, know if this may break anything?

Thanks,
Deepak


Re: [Axis2]setText() adding duplicates to OMElement?

Posted by Deepak Bhole <db...@redhat.com>.
On Fri, 2006-02-10 at 11:11 +0600, Saminda Abeyruwan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Resended the payload with [Axis2] prefix
> 

Doh! Sorry :(

Thanks for spotting it and resending.

Deepak


Re: [Axis2]setText() adding duplicates to OMElement?

Posted by Saminda Abeyruwan <sa...@opensource.lk>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Resended the payload with [Axis2] prefix

Deepak Bhole wrote:
> Hi,
> 
> I have come across an interesting (bug?) in Axiom. As I am still new to
> Axis, I wanted to know others thoughts before I went around making
> patches in critical components, as it may have far reaching consequences
> that I am not aware of yet.
> 
> I enabled REST support and in an attempt to trace code paths, I set up a
> simple example with the "echo" service. The payload sent to the server
> contains a <Text>sdf</Text> element, and the server is expected to
> change this to <Text>Changed by service</Text>.
> 
> I noticed that the payload sent was correct, but what the server sent
> back was <Text>sdfChanged by service</Text>. So I checked it out to see
> why that "sdf" was still there. Here is what is happening:
> 
> HTTPTransportUtils.createEnvelopeFromGetRequest() calls
> omEle.setText(value)
> 
> omEle is an OMElement. In OMElement.setText(), there is the line:
> 
> this.addChild(OMAbstractFactory.getOMFactory().createText(this, text));
> 
> This is causing a duplicate entry because OMFactory.createText() creates
> an OMTextImpl (which extends OMNodeImpl), and OMNodeImpl's constructor
> has a call to addChild() on the parent.
> 
> Thus, in short, setText() calls createText() which causes the text
> element to be added as a child to the parent, and then further down,
> setText() calls addChild() explicitly, causing the text child to be
> added again. This is why that "sdf" was showing up in the response
> message, because only the first "sdf" node was being removed when I
> called setText() on server side.
> 
> I was thinking of removing the explicit addChild() call in setText().
> This seems to be a workable solution with no side-effects. Does anyone
> who knows the code better, know if this may break anything?
> 
> Thanks,
> Deepak
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD7CB0YmklbLuW6wYRAqX7AJwP8NVqnpidF2w9dBLHEiNDHd6iCACgmjAY
VPxmZ9MHAjdbMh6TpRorwWc=
=YhC8
-----END PGP SIGNATURE-----