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
