I think that the following line of code might be the culprit: (via the MAPAggregator interceptor)
ContextUtils.getActionFromServiceModel(Message, Exception): line: 722 action = (String) message.get(SoapBindingConstants.SOAP_ACTION); When setting up the outgoing headers, it looks to create the Action from the service model. Oddly, it looks first to find if there is a SOAPAction defined for the Message, and if not moves on to the wsaw:Action field. I would argue that the line looking to the SOAPAction value be removed entirely as it's not an applicable value for a response message. Does this sound right? if so I can submit a patch to get it fixed asap. Rebecca dkulp wrote: > > > Actually, the OTHER problem is that we're even setting a SOAPAction on the > response message. That's really not needed. Thus, that MAY be the real > bug. If that wasn't set, then it wouldn't find it and thus it would use > the > Action header. > > Dan > > > On Thu December 3 2009 2:58:04 pm Daniel Kulp wrote: >> On Wed December 2 2009 11:41:45 pm Craig Tataryn wrote: >> > Anyone have an inkling as to whether CXF is interpreting the spec >> > correctly on this? Essentially we have an explicit wsaw:Action >> > specified on a response message, yet because there is a soapAction set >> > in the binding the wsaw:Action is ignored and replaced with the value >> > of the soapAction. >> >> Yea. This does seem backwords. Checked the spec: >> >> http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#actioninwsdl >> >> "WS-Addressing defines a global attribute, wsaw:Action, that can be used >> to >> explicitly define the value of the [action] property for messages in a >> WSDL >> description. The type of the attribute is xs:anyURI and it is used as an >> extension on the WSDL input, output and fault elements. A SOAP binding >> can >> specify SOAPAction values for the input messages of operations. In the >> absence of a wsaw:Action attribute on a WSDL input element where a >> SOAPAction value is specified, the value of the [action] property for >> the >> input message is the value of the SOAPAction specified." >> >> Thus, if that is what's occuring, it's backwords. >> >> I think the problem stems from : >> http://www.w3.org/TR/2006/REC-ws-addr-soap-20060509/ >> which states that for SOAP 1.1, the SOAPAction and Action header have to >> match. If not, a fault needs to be thrown. Thus, we grab the >> SOAPAction. However, we should be resetting the SOAPAction to the >> Action. >> (although, if you are using SOAP 1.1, I would probably argue that your >> wsdl is then "not correct" and the SOAPAction and Action should be set >> to >> the same) >> >> >> Dan >> >> > Thanks, >> > >> > Craig. >> > >> > On Fri, Nov 27, 2009 at 10:54 AM, rduhard <[email protected]> wrote: >> > > I'm currently implementing WS-Addressing in my web service and am a >> > > little confused about the way CXF is populating the wsa:Action >> property >> > > on the response message. Our WSDL (provided, not created) defines an >> > > input and output message like this with corresponding wsaw:Action >> > > attributes defined: >> > > >> > > <wsdl:portType name="myMessage"> >> > > ... >> > > <wsdl:input message="messageType" >> wsaw:Action="ns:messageType.version" >> > > /> <wsdl:output message="messageType-Response" >> > > wsaw:Action="ns:messageType-Response.version" /> >> > > ... >> > > </wsdl:portType> >> > > >> > > There is also a soapAction defined in the <wsdl:binding> section: >> > > ... >> > > <soap:operation soapAction="ns:messageType.version" /> >> > > ... >> > > >> > > From what I understand, the SOAPAction value is used in the HTTP >> > > Request Header as information to the receiving server endpoint. But >> on >> > > the outbound message, when populating the wsa:Action field in the >> > > outgoing SOAP Headers, CXF first checks for the soapAction element >> and >> > > if it doesn't find one, it then looks for the wsaw:Action value >> defined >> > > on the output message. >> > > >> > > I"m not sure if I'm missing something, but this seems backwards. I'm >> > > defining an explicit value for the Action on the response message but >> > > it first looks to the soapAction which I don't think should really >> > > apply to the outbound message. >> > > >> > > The only way I can get it to select my explicitly defined wsaw:Action >> > > value on the output is to remove the soapAction attribute from the >> WSDL >> > > (or set it to empty string). However, this isn't an option going >> > > forward as we are not the authors of the WSDL. >> > > >> > > Is it possible that CXF has implemented this wrong and has the action >> > > look-up backwards? >> > > >> > > Thanks in advance, any help/ideas/insight is appreciated. >> > > >> > > >> > > -- >> > > View this message in context: >> > > >> http://old.nabble.com/WSDL-wsaw%3AAction-vs-soapAction-in-MAPs-on-the-r >> > >es ponse-message-tp26545030p26545030.html Sent from the cxf-user >> mailing >> > > list archive at Nabble.com. >> > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > > -- View this message in context: http://old.nabble.com/WSDL-wsaw%3AAction-vs-soapAction-in-MAPs-on-the-response-message-tp26545030p26635939.html Sent from the cxf-user mailing list archive at Nabble.com.
