nextSibling and previousSibling pointers are corrupted when adding same om
element object twice
-----------------------------------------------------------------------------------------------
Key: WSCOMMONS-217
URL: https://issues.apache.org/jira/browse/WSCOMMONS-217
Project: WS-Commons
Issue Type: Bug
Components: AXIOM
Reporter: Mike Rheinheimer
When adding the same OMElement object as a child, the nextSibling and
previousSibling pointers get corrupted in such a way that we can't tell what
child will be detached if detach is called. The code below is a snippet from
the attached .java file. It may be simpler to just grab it and run it
depending on your environment. The code below demonstrates what happens:
String omAsString = "<soapenv:Envelope
xmlns:wsa=\"http://www.w3.org/2005/08/addressing\"; " +
"xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\";>" +
"<soapenv:Header></soapenv:Header>" +
"<soapenv:Body></soapenv:Body>" +
"</soapenv:Envelope>";
...
OMDocument doc = poc.getOM();
//Get Envelope
OMElement root = doc.getOMDocumentElement();
//Get Header
OMElement header = poc.getHeader(root);
OMElement block1 = poc.createHeaderBlock(doc,
"Block_1");
OMElement block2 = poc.createHeaderBlock(doc,
"Block_2");
header.addChild(block1);
// add the first one again
header.addChild(block1);
header.addChild(block2);
//detach header's first child
OMNode first = header.getFirstChildWithName(new
QName("Mike", "Block_1"));
first.detach();
//let's see if the detach succeeded
System.out.println(root.toString());
Will output (hand-formatted for readability):
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:wsa="http://www.w3.org/2005/08/addressing";>
<soapenv:Header>
<wsse:Block_1 xmlns:wsse="Mike"></wsse:Block_1>
</soapenv:Header>
<soapenv:Body></soapenv:Body>
</soapenv:Envelope>
Notice which element(s) got detached. That's ugly. I'm not sure how we might
address this. I think it makes sense that a user of axiom code should be
careful not to add the same object twice, but is there some checking
(performant checking, that is) we could be doing in the addChild method to
prevent this situation?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
