Andrew Dinn [http://community.jboss.org/people/adinn] replied to 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/549489#549489 -------------------------------------------------------------- Yes, I assumed there woud lbe further problems. This may require a few chnages from me -- for example I may need to provide a real implemntation of SoapFaultService rather than just adding a doapFault(Fault) WebMethod to the WS-T service endpoint beans. If you can get past the problems with interceptors not expecting  soap faults let me know what else breaks. I am not sure how big an issue this is for CXF. It ought to be perfectly legitimate to define (as I have done) a  JaxWS service whose web methods accept a single soap fault as argument. In practice I am not clear what the implications are of requiring this to be supported. It is quite possible for the implementation to isolate the case where a fault is being delivered as an incoming payload from the case where it is being returned from a failed (OneWay or RPC) request. However,  this implies that the handler stack has to discriminate these cases by evaluating somthing like isRequest() && isFault() rather than just isFault(). This wioudl most likely work but it is not acceptable for this specific service. The spec requires that a soap fault be delivered to the endpoint at the FaulttTo address. This is critical for interoperability. Alternative implementations of WS-T such as the ones provided by Microsoft, IBM  and Sun will expect my services to send a soap fault to their endpoints and will be sendng soap faults to my endpoint. n.b. this problem can also arise with synchronous fault delivery on any JaxWS request when using WSA. This is because when using WSA it is possible to configure a FaultTo endpoint which is not the same as the From endpoint. So, if, for example, delivery of a OneWay message failed because of a problem with a mustUnderstand header the fault should be routed to the FaultTo endpoint rather than returned to the sender on the HTTP connection used to make the request. So, the fault will still be an incoming message for the FaultTo endpoint; it wiill not be paired with an outgoing message. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/549489#549489] Start a new discussion in JBoss Web Services CXF at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]