Thanks to all who helped me to tackle this problem!
2012/6/26 Marco Pas <[email protected]>: > The solution of Dan did the trick... > > I implemented the following interceptor: > > public class SetReplyToSOAPHeaderInInterceptor extends > AbstractSoapInterceptor { > > public SetReplyToSOAPHeaderInInterceptor() { > super(Phase.USER_PROTOCOL); > } > > @Override > public void handleMessage(SoapMessage message) throws Fault { > AddressingProperties ap = ContextUtils.retrieveMAPs(message, > true, false); > EndpointReferenceType epr = new EndpointReferenceType(); > AttributedURIType aut = new AttributedURIType(); > aut.setValue("http://www.w3.org/2005/08/addressing/anonymous";); > epr.setAddress(aut); > ap.setReplyTo(epr); > } > } > > 2012/6/26 Aki Yoshida <[email protected]>: >> Hi Marco, >> >> okay. In certain cases, one can use CXF's transform feature to perform >> this kind of message modification. In your particular case, if your >> inbound message has only one <Address> tag. (that would be the case if >> you have only <ReplyTo> and no other address related fields), you can >> use the transform feature's replace mode to replace the content of >> this Address element to the anonymous target (e.g., >> http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous or >> whatever its variant of that addressing namespace). >> >> See >> http://cxf.apache.org/docs/transformationfeature.html#TransformationFeature-Replacingtextcontent >> >> The current limitation of the transform feature is that you can't use >> a path notation to pick a node in a specific path. This is the reason >> why this feature will help you only if your message has only one >> Address element that can be matched with the current one-node syntax. >> >> If this is not the case, you have to write your own interceptor, as >> Dan described. >> >> regards, aki >> >> 2012/6/25 Marco Pas <[email protected]>: >>> Hi Aki, >>> >>> Thanks for your reply, the clients is sending the ws addressing >>> property in the wrong way. It is build expecting to get synchronous >>> feedback, but it send a replyTo field filled with content making the >>> call asynchronous. So the HTTP 202 is returned. >>> So i was looking for ways on skipping the HTTP 202, but it seems that >>> if i modifing the replyto header field should make it ok. Looking for >>> a way to modify the replyTo property and make it synchronous, whatever >>> the client is sending. >>> I am aware that this is a rather strange solution and we should fix >>> the client, but that is not in my reach to do so. >>> >>> Grtz >>> >>> 2012/6/25 Aki Yoshida <[email protected]>: >>>> Hi Marco, >>>> Is your client expecting some specific response message in the http >>>> response? >>>> >>>> The HTTP 202 response code is used for the HTTP response for a oneway >>>> service call that returns no content or a request-response service >>>> call, where the real response is configured to be sent back to another >>>> port. >>>> >>>> I am not sure about your scenario. Is your client a oneway service >>>> client that can't handle the HTTP 202 and expects the HTTP 200 with an >>>> empty content or an empty SOAP envelope? Or it is a request-response >>>> service client? >>>> >>>> regards, aki >>>> >>>> 2012/6/25 Marco Pas <[email protected]>: >>>>> Hi there, i am looking for ways to skip the HTTP 202 reponse send back >>>>> by CXF when using WS Addressing. >>>>> We need to support clients that are not capable of handling the HTTP >>>>> 202 response. The operate in a request-response mode and not >>>>> are not able to handle the HTTP 202 returned by CXF. >>>>> >>>>> Is there any way to skip the HTTP 202 reponse ? >>>>> >>>>> /Marco
