[jbossts-issues] [JBoss JIRA] Closed: (JBTM-753) FaultTo ednpoints provided to allow asynchronous soap fault Delivery specify wrong service/endpoint

FaultTo ednpoints provided to allow asynchronous soap fault Delivery specify wrong service/endpoint --------------------------------------------------------------------------------------------------- Key: JBTM-753 URL: https://jira.jboss.org/browse/JBTM-753 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public(Everyone can see) Components: XTS Affects Versions: 4.11.0 Reporter: Andrew Dinn Assignee: Andrew Dinn The move to CXF 2.2.9 has identified a problem with the mechanism used by the WS-T services to deliver asynchronous soap faults. Each (OneWay) service request includes a FaultTo endpoint which addresses to the pair service/port and this endpoint is used to deliver soap faults reporting any problems which may arise after the one way message has been delivered. So, for example when the Participant service running in a transactional web service's container is sent a Prepare request the FaultTo endpoint addresses the Coordinator service running in the JBossTS/XTS coordinator's container. Soap faults are sent using JaxWS by invoking a proxy cloned from a SoapFaultService instance. All the WS-T endpoints implement the web method declared by this service so they can handle the incoming request. Unfortunately, with CXF 2.2.9 the endpoint now includes metadata identifying the originating service/port used when the endpoint is created. The client validates any proxy create (getPort) request against this metadata. Since the endpoint and create refer to different services getPort fails. The endpoint should either be created with no metadata or should contain metadata for the SoapFaultService and associated port. It may still be appropriate to address the fault back to the WS-T service or it may be necessary to install a distinct endpoint for a SoapFaultService and have it route faults to the relevant WS-T service. Which of these is necessary depends upon the outcome of a related JBossWS issue addressing this problem from the CXF side (JBWS-3069)