[jbossws-issues] [JBoss JIRA] Updated: (JBWS-3095) WRONG_DOCUMENT_ERR when accessing SOAPMessage DOM using WebServiceProvider and Provider<SOAPMessage>

[Alessio Soldano (JIRA)]

     [ https://jira.jboss.org/browse/JBWS-3095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBWS-3095:
----------------------------------

    Fix Version/s:     (was: jbossws-native-3.4.1)


> WRONG_DOCUMENT_ERR when accessing SOAPMessage DOM using WebServiceProvider and Provider<SOAPMessage>
> ----------------------------------------------------------------------------------------------------
>
>                 Key: JBWS-3095
>                 URL: https://jira.jboss.org/browse/JBWS-3095
>             Project: JBoss Web Services
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: jbossws-native
>    Affects Versions: jbossws-native-3.3.1
>         Environment: JBossAS Community 5.1, JBoss ESB 4.8, JBossWS-Native 3.3.1, upgraded Xalan-Java 2.7.1
>            Reporter: Ray Cardillo
>
> While converting some code from JBossWS-Metro to JBossWS-Native, we have been working through a bug that seems to be related to XML parsing inconsistencies due to the different DOM implementations that are used by the two technologies.  We have a web service that is using the @WebServiceProvider feature of JAX-WS to create a custom Provider<SOAPMessage> so we can parse the XML directly.  However, any time we try to extract the XML, in any number of ways, it causes an internal "expandToDOM" to be called that ends up failing due to a WRONG_DOCUMENT_ERR.  At first we thought we were doing something incorrectly, but after careful analysis, and experimenting with many different ways of getting elements from the incoming SOAPMessage, we see this same stack trace in each case.  So it looks like there is a bug in the internal expansion.
> org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is used in a different document than the one that created it.
> 	at org.apache.xerces.dom.ParentNode.internalInsertBefore(Unknown Source)
> 	at org.apache.xerces.dom.ParentNode.insertBefore(Unknown Source)
> 	at org.apache.xerces.dom.NodeImpl.appendChild(Unknown Source)
> 	at org.jboss.ws.core.soap.NodeImpl.appendChild(NodeImpl.java:481)
> 	at org.jboss.ws.core.soap.SOAPContentElement.appendChild(SOAPContentElement.java:467)
> 	at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:264)
> 	at org.jboss.ws.core.soap.SOAPContentElement.addChildElement(SOAPContentElement.java:192)
> 	at org.jboss.ws.core.soap.XMLContent.expandContainerChildren(XMLContent.java:355)
> 	at org.jboss.ws.core.soap.XMLContent.transitionTo(XMLContent.java:105)
> 	at org.jboss.ws.core.soap.SOAPContentElement.transitionTo(SOAPContentElement.java:143)
> 	at org.jboss.ws.core.soap.SOAPBodyElementDoc.transitionTo(SOAPBodyElementDoc.java:85)
> 	at org.jboss.ws.core.soap.SOAPContentElement.expandToDOM(SOAPContentElement.java:532)
> 	at org.jboss.ws.core.soap.SOAPContentElement.getFirstChild(SOAPContentElement.java:488)
> 	...
> This same stack trace occurs if trying to do anything that requires extracting Nodes or Elements from the SOAPMessage.
> Example 1:
> 	Node node = msg.getBody();
> 	or
> 	Node node = msg.getBody().getFirstChild();
> 	or
> 	Node node = iterate over msg.getBody().getChildNodes();
> 	or
> 	Node node = iterate over msg.getBody().getChildElements();
> 	...
> 	StringWriter sw = new StringWriter();
> 	tr.transform(new DOMSource(node), new StreamResult(sw));
> 	...
> Example 2:
> 	msg.getBody().getChildElements();
> 	...
> 	SAAJResult sr = new SAAJResult(element);
> 	sr.getResult();
> 	...

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira