[
https://jira.jboss.org/jira/browse/JBWS-2166?page=com.atlassian.jira.plug...
]
Andrew Dinn commented on JBWS-2166:
-----------------------------------
This same issue also appears to be causing regular failures when running the xts unit
tests. However, in this case the offending reference parameter is not obtained from an
incoming addressing context. In this case it is created from scratch using a soap factory
and then attached to the faultto endpoint of an addressing context prior to a client
invocation. It is hard to know what to do to work around this manifestation of the
problem. After all if the soap element as originally created will causes a dom error why
would it make any difference cloning the associated node and then using a soap factory to
create a new soap element tree from the cloned dom node?
This issue does not appear to be breaking the xts implementation itself (the demo still
appears to run ok -- I'll be trying the rest of the system tests very soon). However,
it is rather worrying that the unit tests are failing. This really needs fixing before 5.1
is released.
WSA client handler throws exception when installing reference
parameters
------------------------------------------------------------------------
Key: JBWS-2166
URL:
https://jira.jboss.org/jira/browse/JBWS-2166
Project: JBoss Web Services
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: jbossws-native
Affects Versions: jbossws-native-3.0.1
Reporter: Andrew Dinn
WSAddressingClientHandler.handleOutbound in package
org.jboss.ws.extensions.addressing.jaxws is throwing the following exception when
inserting reference parameters into a reply:
10:52:44,104 ERROR [SOAPFaultHelperJAXWS] SOAP request exception
javax.xml.ws.WebServiceException: org.w3c.dom.DOMException: WRONG_DOCUMENT_ERR: A node is
used in a different document than the one that created it.
at
org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.processHandlerFailure(HandlerChainExecutor.java:276)
at
org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:155)
at
org.jboss.ws.core.jaxws.client.ClientImpl.callRequestHandlerChain(ClientImpl.java:191)
at org.jboss.ws.core.CommonClient.invoke(CommonClient.java:298)
at org.jboss.ws.core.jaxws.client.ClientImpl.invoke(ClientImpl.java:302)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:172)
at org.jboss.ws.core.jaxws.client.ClientProxy.invoke(ClientProxy.java:152)
at $Proxy93.soapFault(Unknown Source)
at
com.arjuna.webservices11.wsaddr.client.SoapFaultClient.sendSoapFault(SoapFaultClient.java:72)
at
com.arjuna.webservices11.wsat.client.ParticipantClient.sendSoapFault(ParticipantClient.java:150)
at
com.arjuna.wst11.messaging.CoordinatorProcessorImpl.sendInvalidState(CoordinatorProcessorImpl.java:272)
at
com.arjuna.wst11.messaging.CoordinatorProcessorImpl.prepared(CoordinatorProcessorImpl.java:176)
at
com.arjuna.webservices11.wsat.sei.CoordinatorPortTypeImpl$1.executeTask(CoordinatorPortTypeImpl.java:61)
at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:65)
at java.lang.Thread.run(Thread.java:595)
Caused by: 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:477)
at org.jboss.ws.core.soap.SOAPHeaderImpl.appendChild(SOAPHeaderImpl.java:198)
at org.jboss.ws.core.soap.SOAPElementImpl.addChildElement(SOAPElementImpl.java:274)
at org.jboss.ws.core.soap.SOAPHeaderImpl.addChildElement(SOAPHeaderImpl.java:70)
at
org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.appendElement(SOAPAddressingPropertiesImpl.java:374)
at
org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.appendElements(SOAPAddressingPropertiesImpl.java:352)
at
org.jboss.ws.extensions.addressing.soap.SOAPAddressingPropertiesImpl.writeHeaders(SOAPAddressingPropertiesImpl.java:306)
at
org.jboss.ws.extensions.addressing.jaxws.WSAddressingClientHandler.handleOutbound(WSAddressingClientHandler.java:113)
at org.jboss.ws.core.jaxws.handler.GenericHandler.handleMessage(GenericHandler.java:55)
at
org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:295)
at
org.jboss.ws.core.jaxws.handler.HandlerChainExecutor.handleMessage(HandlerChainExecutor.java:140)
... 13 more
The situation which manifests this problem is as follows:
Client A attaches WS AddressingProperties to a port for server B, It installs a ReplyTo
epr whose address identifies server A. It attaches a reference parameter wsarj:identifier
to the epr. Client A then invokes service B.
The implementation method of service B retrieves the request AddressingProperties from
its message context and sets up a reply AddressingProperties instance by calling
AddressingProperties.initializeAsReply. It obtains a port for service A, installs the
reply properties on the port then invokes service A. The client handler under this
invocation gets the error.
The problem is that the SOAP implementation does not copy the reference parameter Element
instance when it tries to insert them into the outgoing message. intiializeAsReply
retrieves these elements from the incoming context ReplyTo/FaultTo and adds them to the
element extension list of the reply addressing context. The client handler calls
SOAPAddressingHandlerImpl.writeHeaders to add these elements as headers in the outbound
message. writeHeaders eventually calls SOAPHeaderImpl.addChildElement to add each
reference parameter Element to the outgoing message header. addChildElement tests whether
the Element is a SOAP element and, if so, assumes that it can be inserted directly into
the outgoing message by calling appendElement. Unfortunately, the incoming reference
parameters are associated with a dom node whose document is non-null and this
barfs,claiming that someone is attempting a switcheroo on the document.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira