Any chance you can try with the latest 2.4.3-SNAPSHOT code?
Jesse Pangburn and Aki Yoshida have done a lot of work on the WS-Addressing support of the Dispatch clients/servers. See: https://issues.apache.org/jira/browse/CXF-3755 https://issues.apache.org/jira/browse/CXF-3783 https://issues.apache.org/jira/browse/CXF-3747 https://issues.apache.org/jira/browse/CXF-3748 https://issues.apache.org/jira/browse/CXF-3749 Thus, it may already be fixed. If not, can you provide a test case? Thanks! Dan On Thursday, September 22, 2011 12:51:15 PM Malisetti, Ramanjaneyulu wrote: > Hi, > Another issue I have come across during migrating our code from CXF 2.3 > to 2.4.2. > > Basically we two clients that use 1) Dispatch<Source> 2) > Dispatch<SOAPMessage>. For both the clients we set <To> and <Action> > entries in Soap Header using CXF WSAddressingUtil. Our service mandates > request to have WS-Addressing element. > > We have no issue for the client that use Dispatch<Source>. But for client > that use Dispatch<SOAPMessage>, request header is something like below i.e > if X is a To address, CXF is putting XX and for action element also it is > adding > http://cxf.apache.org/jaxws/dispatch/WrappedSinkPortType/InvokeRequest > after our value. > > > <SOAP-ENV:Envelope > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";> > <SOAP-ENV:Header> > <To xmlns="http://www.w3.org/2005/08/addressing";>XX</To> > <Action > xmlns="http://www.w3.org/2005/08/addressing";>http://www.w3.org/2010/08/ws-e > vt/NotifyEventhttp://cxf.apache.org/jaxws/dispatch/WrappedSinkPortType/Invok > eRequest</Action<http://www.w3.org/2010/08/ws-evt/NotifyEventhttp:/cxf.apach > e.org/jaxws/dispatch/WrappedSinkPortType/InvokeRequest%3c/Action>> > </SOAP-ENV:Header> > </SOAP-ENV:Envelope> > > This is breaking our server side code. Is there way to avoid this behavior? > > If I disable addressing, my server is not accepting requests from client > that use Dispatch<SOAPMessage> > > Thank you in advance. > > Regards > Raman -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
