[jboss-user] [JBoss Web Services CXF] - Continuing problem with XTS WS-T tests in AS trunk/CXF 2.2.9

[Andrew Dinn]

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

--------------------------------------------------------------
> Jim Ma wrote:
> 
> After looked at the testcase, I think fix this NPE can not resolve this problem completely. If I understand correctly , after server receive this "soapFault" request, it still needs to invoke the method "soapFault(Fault fault)" in service imlementation class.  So far , CXF is not capable to do this.  It is because the CXF Intercetors to process soapFault is only designed to work in the client side.  So fix this one , there will be couple of another issues pop up.
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().
> Jim Ma wrote:
> 
> This could be a workaroud: modify the wsdl schema and wrap the soap fault element in another element:
> > <xs:element name="XTSFault" type="tns:XTSFault"/>
> >   <complexType name="XTSFault">
> >    <sequence>
> >        <element name="fault" type="soapEnv:Fault"/>
> >    </sequence>
> >   </complexType>
> > 
> > <message  name="SoapFault">
> >       <part name="fault"  element="tns:XTSFault" />
> > </message>
> This will make CXF treat this soap request not a soap fault response and handle it correctly.
> Does this change need a lot of work in JBossTS and work for dispatching the fault message ?
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&containerType=14&container=2046]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20100624/988bf791/attachment.html