You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by rduhard <re...@duhard.ca> on 2009/11/27 17:54:47 UTC
WSDL wsaw:Action vs soapAction in MAPs on the response message
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-response-message-tp26545030p26545030.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by Daniel Kulp <dk...@apache.org>.
Rebecca,
On Tue January 26 2010 5:12:34 pm rduhard wrote:
> Logged an issue in Jira with potential patch. See
> https://issues.apache.org/jira/browse/CXF-2629
Just to let you know that I looked at this a bit last night. With your
patch, a BUNCH of the WS-RM related system tests fail. I think it's a bug in
the way WS-RM is setting up it's service model, but I need to dig in more to
figure out what is going on with it. That's basically the cause of the delay
in applying the patch.
Dan
> 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 <re...@duhard.ca> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by rduhard <re...@duhard.ca>.
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 <re...@duhard.ca> 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
> dkulp@apache.org
> 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.
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by Daniel Kulp <dk...@apache.org>.
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 <re...@duhard.ca> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by rduhard <re...@duhard.ca>.
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 <re...@duhard.ca> 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
> dkulp@apache.org
> 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.
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by Daniel Kulp <dk...@apache.org>.
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 <re...@duhard.ca> 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
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by rduhard <re...@duhard.ca>.
I think your comments might only refer to a request message.. so just to be
clear, we are only referring to the response message. The SOAPAction and
Action field for the input message are the same in our wsdl, and are being
sent and handled correctly.
However, on our output message, CXF is using the SOAPAction value and not
selecting the explicit output wsaw:Action defined because it looks to
SOAPAction first. I'm pretty sure the SOAPAction value should be irrelevant
on the response solely based on the definition of the SOAPAction field.
"The SOAPAction HTTP request header field can be used to indicate the intent
of the SOAP HTTP request. The value is a URI identifying the intent. SOAP
places no restrictions on the format or specificity of the URI or that it is
resolvable. An HTTP client MUST use this header field when issuing a SOAP
HTTP Request."
The http://www.w3.org/TR/2006/CR-ws-addr-wsdl-20060529/#actioninwsdl spec is
rather vague on the response requirements, but based on what is stated about
SOAPAction and how the spec refers to it's usage on the input w.r.t.
choosing the appropriate value, I think that CXF is retrieving the output
Action in the wrong order (and arguably it should ignore SOAPAction all
together on the response).
Again, I'm only referring to the response WS-A values but am I possibly
misinterpreting something?
Rebecca
dkulp 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 <re...@duhard.ca> 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-res
>> >ponse-message-tp26545030p26545030.html Sent from the cxf-user mailing
>> list
>> > archive at Nabble.com.
>>
>
> --
> Daniel Kulp
> dkulp@apache.org
> 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-tp26545030p26632713.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by Daniel Kulp <dk...@apache.org>.
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 <re...@duhard.ca> 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-res
> >ponse-message-tp26545030p26545030.html Sent from the cxf-user mailing list
> > archive at Nabble.com.
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: WSDL wsaw:Action vs soapAction in MAPs on the response message
Posted by Craig Tataryn <cr...@tataryn.net>.
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.
Thanks,
Craig.
On Fri, Nov 27, 2009 at 10:54 AM, rduhard <re...@duhard.ca> 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-response-message-tp26545030p26545030.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger