You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Mike Rheinheimer (JIRA)" <ji...@apache.org> on 2007/07/13 22:50:04 UTC
[jira] Created: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Commented: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512622 ]
Rich Scheuerle commented on WSCOMMONS-217:
------------------------------------------
Adding assertion checks to each call of addChild will degrade performance.
Is it possible to add these kinds of checks but gate them with an ASSERTION_CHECK flag.
boolean ASSERTION_CHECK = log.isDebugEnabled();
public void addChild(OMNodeImpl child) {
if (ASSERT_CHECK) {
_assertAddChild(OMNode child);
}
....
}
protected void _assertAddChild(OMNode child) {
<if adding an existing child...throw exception>
<if adding a parent or ancestor ...throw exception>
etc...
}
> 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
> Attachments: InsertHeaders.java
>
>
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Updated: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WSCOMMONS-217:
---------------------------------------
Attachment: InsertHeaders.java
for private testing
> 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
> Attachments: InsertHeaders.java
>
>
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Updated: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle updated WSCOMMONS-217:
-------------------------------------
Attachment: patch.txt
Here is a targetted fix and test.
> 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
> Attachments: InsertHeaders.java, patch.txt
>
>
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Resolved: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle resolved WSCOMMONS-217.
--------------------------------------
Resolution: Fixed
Revison = 577957
> 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
> Assignee: Rich Scheuerle
> Attachments: InsertHeaders.java, patch.txt
>
>
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Assigned: (WSCOMMONS-217) nextSibling and previousSibling
pointers are corrupted when adding same om element object twice
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WSCOMMONS-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rich Scheuerle reassigned WSCOMMONS-217:
----------------------------------------
Assignee: Rich Scheuerle
> 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
> Assignee: Rich Scheuerle
> Attachments: InsertHeaders.java, patch.txt
>
>
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org