1:57 p.m.
[
https://jira.jboss.org/browse/JBWS-3095?page=com.atlassian.jira.plugin.sy...
]
Ray Cardillo commented on JBWS-3095:
------------------------------------
FYI, after much experimentation, a workaround is to copy the message. I tried this after
seeing other (older) reports that something in DOMUtils was causing similar problems in
the past because it uses a Thread local variable to keep tract of the Document instance
(or something like that). So presumably copying the entire incoming SOAPMessage Document
and then using the resulting Nodes puts everything in the right context (as opposed to
trying to use the Nodes from the incoming Document directly). This is not a satisfying
solution because it requires us to copy every incoming message, and some can be large, but
it does seem to be a functional workaround otherwise.
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.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira