Logged an issue in Jira with potential patch. See https://issues.apache.org/jira/browse/CXF-2629
Rebecca dkulp wrote: > > On Fri December 4 2009 11:15:27 am rduhard wrote: >> 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. > > For the response, yes. That does sound correct. > > Dan > > > >> >> 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-tp26545030p27330727.html Sent from the cxf-user mailing list archive at Nabble.com.
