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

[Jim Ma]

Jim Ma [http://community.jboss.org/people/jim.ma] 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/549617#549617

--------------------------------------------------------------
> 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.
OK. I will continue to look at this issue in CXF and give you update.
> 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().
Agreed.  I need to change the current code to route the asynchronous fault to the server pipeline to process the normal soap request.  I'll figure out and shoot the blocks for this request in CXF.

> 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.
This could be a common user case for Fault message will be delievered to another Endpoint not the sender .  I remembered a similar case in CXF couple of months ago,   the ReplyTo is not the sender and another endpoint with http url address. CXF can not  send this response message to the ReplyTo endpoint correctly. And only with jms transport , it works well . Anyway , I will look at this problem and fix it in CXF. 

--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/549617#549617]

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/20100625/5270e21b/attachment.html