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
