Andrew Dinn [http://community.jboss.org/people/adinn] created the discussion "Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9" To view the discussion, visit: http://community.jboss.org/message/548690#548690 -------------------------------------------------------------- The XTS tests are still seeing some failures on the latest AS trunk with cxf stack 3.3.1.SP1. I think they all appear to stem from a single issue which relates to dispatch of soap faults. It's  not actually CXF's  fault handling which is the problem. The XTS code uses its own JaxWS based service to dispatch faults -- I know that sounds weird but I'll explain that in a minute. Anyway, the problem is not actually to do with the dispatch, routing or receipt of the soap faults, it's to do with creating the relevant JaxWS service. This is a WSDL first service defined as follows: I generated code from  this WSDL using wsconsume (well, actually, I think I generated it using Glassfish's wsimport but essentially it is the same thing) as follows: The problem is that when my tests try to create a SoapFaultPortType I get a parse error during processing of the WSDL. Unfortunately, the error is not reported as being in my WDSL. It ahppens wen processing the imported schema I stepped through the code and found that it successfully loads the schema located at http://schemas.xmlsoap.org/soap/envelope http://schemas.xmlsoap.org/soap/envelope but then runs into problems processing the contents. Here is the error message: As you can see the problem occurs under ServiceImple.<init> below SoapFaultService.<init> when trying to create the SoapFaultService class  generated by wsconsume. This is somewhat bizarre given where the schema comes from. Ok, so you might want an explanationfor what this servcie is and why it needs to import the soap envelope schema. It's abit copnvoluted but here goes. XTS implements the WS-C and WS-T services defined by the WSTX standard. WS-C includes two generic services for creating and enlisting with transactions from various transaction transaction protocols. WS-T includes two families of transaction protocol specific services which allow transaction clients and transactional web services to progress towards completion completion. The service APIs are specified by WSDL and our rimplementation uses JaxWS to implement  that WSDL. The WS-T services (WS-AT atomic transaction and WS-BA business activity), are only mandated only to employ a OneWay MEP. Tthe SOAP used to deliver these messages is required to be configured with various mandatory WSA headers, including MessageId, ReplyTo and FaultTo. The SOAP headers also need to include service specific transaction identifiers as header elements. This is achieved by by installing them as ReferenceParameters in the endpoints used by the transaction protocol services and transactional web services communicate ie. they are attached to * the transaction protocol specific Coordinator service endpoints handed out to transactional web services by the WS-C registration service when they enlist in a transaction * the endpoint in the ReplyTo/FaultTo header included by web services when they negotiate with the registration service or with their Coordinator service Yes, as you can see, the use of one way messaging means that the container for the transactional web service must also contain a WS-AT or WS-BA Initiator service. The Coordinator talks back to this Initiator service in order to be able to constuct a long-running dialogue with the transactional web service composed  of a series of 1-way messages such as e.g. +enlist+, +prepare+, +prepared+, +commit+, +commited+. In the case of WS-BA this dialogue can be initiated asynchronously from either end --  that's why OneWay MEP was chosen over RPC. The service specification mandates that in cases where processing of a message runs into certain error conditions a SoapFault must be dispatched to the FaultTo addess configured in the WSA headers. Obviously, if a fault  occurs in +delivering+ the message the JaxWS layer will dispatch a fault to the sender. But that's not that the spec is talking about (or  at least not +all+ it is talking about). The spec is concerned with faults which occur after delivery when the delivered message is being processed. By this stage JaxWS has done its stuff and told the sender 'message delivered'. If the service endpoint bean were to throw a fault nothing would get dispatched back to  the sender. So, the threads which are handling a request to the Coordinator or Initiator services need to be able to dispatch a fault to the FaultTo address asynchronously -- from a standing start. This fault needs to * be sent to the FaultTo address * provide a WSA RelatesTo header whcih includes the originating MessageId * include the ReferenceParameter header obtained with the FaultTo address. Now the WS-AT/BA coordinator and initiator service enpoint implementation classes all implement a WebMethod which accepts a SoapFault with a specific SOAPAction or WSA Action. This web method is declared by interface SoapFaultPortType generated from the SoapFaultService WSDL and all these services implement the interface i.e.they are capable of acting as an endpoint for the SoapFaultPortType of the SoapFaultService. Now, in order to dispatch an asynchronous SoapFault to the sender the handler thread merely needs to create a fault and an instance of SoapFaultService then clone a proxy port from it and call method soapFault(). So this is what is happening when my current implementation blows up trying to read the soap envelope WSDL. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/548690#548690] Start a new discussion in JBoss Web Services CXF at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]