You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Adrian C <ad...@gmail.com> on 2009/02/02 13:01:26 UTC
ws-a questions
Hi,
Can someone clarify how CXF works with WS-A? I had some unexpected results
where a client was calling our web services with two different SOAP actions
(one on the transport headers, http in this case, the other in the WSA
headers). The WS-A header as it turned out was incorrect however the correct
operation was called? How can this be? I would have though the the following
would happen:
1. Check for ws-a headers & soap action there
2. If no ws-a headers & soap action check for SOAP action in the transport
headers
3. If no action present use the contents of the SOAP:Body to determine what
operation to invoke.
So can anyone clarify?
Thanks.
--
View this message in context: http://www.nabble.com/ws-a-questions-tp21788455p21788455.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: ws-a questions
Posted by Daniel Kulp <dk...@apache.org>.
On Wed February 4 2009 3:32:42 pm Adrian Corcoran wrote:
> Ok have some interesting findings here.
>
> For the sake of arguments image a ws with 2 operations create & delete and
> with corresponding soap actions.
>
> 1. With HTTP if there are conflicting SOAP actions the are caught - i.e.
> HTTP SOAPAction & WSA-SoapAction
Well, that's a good start. :-)
> 2. If I specify a HTTP SOAP Action of create but the body of the soap
> request corresponds to a deleteRequest my create operation invoked is
> invoked!
OK. I know how this is happening and I would probably call it a bug.
1) The SOAPActionInInterceptor uses the soap action to find an Operation.
This is a straight map lookup and is thus very quick if the service has unique
actions for each operation. If not, it falls down to:
2) When it gets into the real "in" interceptor (RPCInInterceptor or
DocLit...), if an Operation hasn't yet been detected, it grabs the first QName
from the XMLStreamReader and tries to map that to the operation.
What probably needs to happen in (2) is if there IS an operation, check the
QName to make sure that QName is valid for that operation. Definitely log a
bug for that.
> 3. If I specify a WSA SOAP Action of create but the body of the soap
> request corresponds to a deleteRequest my delete operation is invoked!
The SOAPActionInInterceptor only looks at the HTTP header. Thus, if it
doesn't say "create", it would fall to (2) above.
Dan
> What is the expected be behaviour here?
>
> I spotted this over JMS first - a client send in a request with a
> SOAPAction on the JMS headers that was at odds with wsa-soap action. I know
> that the SOAPAction as a header for JMS is not part of the spec, but the
> CXF client was population the JMS string property SOAPAction. So in this
> case it seems that there is a difference in behavior!
>
> Btw this is with CXF 2.1.3
>
> On Tue, Feb 3, 2009 at 6:12 PM, Daniel Kulp <dk...@apache.org> wrote:
> > On Mon February 2 2009 7:01:26 am Adrian C wrote:
> > > Hi,
> > >
> > > Can someone clarify how CXF works with WS-A? I had some unexpected
> >
> > results
> >
> > > where a client was calling our web services with two different SOAP
> >
> > actions
> >
> > > (one on the transport headers, http in this case, the other in the WSA
> > > headers).
> >
> > Hmm... That's not good. I checked the WS-Addressing code and the
> > validateIncomingMAPs method should be checking that the two actions are
> > equal
> > and throwing a fault if they aren't.
> >
> > Any chance you can hook up a debugger and make sure that method is
> > getting called?
> >
> > > The WS-A header as it turned out was incorrect however the
> > > correct operation was called? How can this be? I would have though the
> >
> > the
> >
> > > following would happen:
> > >
> > > 1. Check for ws-a headers & soap action there
> >
> > Technically, this SHOULD be irrelevant as the two actions should be
> > identical.
> > The check in MAPAggregator.validateIncomingMAPs should guarantee that.
> > The
> > first step is to make sure that is called.
> >
> > Dan
> >
> > > 2. If no ws-a headers & soap action check for SOAP action in the
> >
> > transport
> >
> > > headers
> > > 3. If no action present use the contents of the SOAP:Body to determine
> >
> > what
> >
> > > operation to invoke.
> > >
> > > So can anyone clarify?
> > >
> > > Thanks.
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://www.dankulp.com/blog
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: ws-a questions
Posted by Adrian Corcoran <ad...@gmail.com>.
Hi,
Know you guys have been up to your neck with the release of 2.1.4 but anyone
get a chance to have a look into this?
Thanks,
Adrian
On Thu, Feb 5, 2009 at 10:10 AM, Adrian C <ad...@gmail.com> wrote:
>
> actually what I am saying about a difference in behaviour between JMS &
> HTTP
> may be a red herring - we don't use CXF's JMS Config to receive messages
> (we
> receive messages over JMS and then send them on a local transport) and as
> it
> turns out we were discarding the SOAPAction on the JMS headers.
>
> But other issues below still exist.
>
>
>
> Adrian C wrote:
> >
> > Ok have some interesting findings here.
> >
> > For the sake of arguments image a ws with 2 operations create & delete
> and
> > with corresponding soap actions.
> >
> > 1. With HTTP if there are conflicting SOAP actions the are caught - i.e.
> > HTTP SOAPAction & WSA-SoapAction
> > 2. If I specify a HTTP SOAP Action of create but the body of the soap
> > request corresponds to a deleteRequest my create operation invoked is
> > invoked!
> > 3. If I specify a WSA SOAP Action of create but the body of the soap
> > request
> > corresponds to a deleteRequest my delete operation is invoked!
> >
> > What is the expected be behaviour here?
> >
> > I spotted this over JMS first - a client send in a request with a
> > SOAPAction
> > on the JMS headers that was at odds with wsa-soap action. I know that the
> > SOAPAction as a header for JMS is not part of the spec, but the CXF
> client
> > was population the JMS string property SOAPAction. So in this case it
> > seems
> > that there is a difference in behavior!
> >
> > Btw this is with CXF 2.1.3
> >
> > On Tue, Feb 3, 2009 at 6:12 PM, Daniel Kulp <dk...@apache.org> wrote:
> >
> >> On Mon February 2 2009 7:01:26 am Adrian C wrote:
> >> > Hi,
> >> >
> >> > Can someone clarify how CXF works with WS-A? I had some unexpected
> >> results
> >> > where a client was calling our web services with two different SOAP
> >> actions
> >> > (one on the transport headers, http in this case, the other in the WSA
> >> > headers).
> >>
> >> Hmm... That's not good. I checked the WS-Addressing code and the
> >> validateIncomingMAPs method should be checking that the two actions are
> >> equal
> >> and throwing a fault if they aren't.
> >>
> >> Any chance you can hook up a debugger and make sure that method is
> >> getting
> >> called?
> >>
> >>
> >> > The WS-A header as it turned out was incorrect however the
> >> > correct operation was called? How can this be? I would have though the
> >> the
> >> > following would happen:
> >> >
> >> > 1. Check for ws-a headers & soap action there
> >>
> >> Technically, this SHOULD be irrelevant as the two actions should be
> >> identical.
> >> The check in MAPAggregator.validateIncomingMAPs should guarantee that.
> >> The
> >> first step is to make sure that is called.
> >>
> >> Dan
> >>
> >>
> >> > 2. If no ws-a headers & soap action check for SOAP action in the
> >> transport
> >> > headers
> >> > 3. If no action present use the contents of the SOAP:Body to determine
> >> what
> >> > operation to invoke.
> >> >
> >> > So can anyone clarify?
> >> >
> >> > Thanks.
> >>
> >> --
> >> Daniel Kulp
> >> dkulp@apache.org
> >> http://www.dankulp.com/blog
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/ws-a-questions-tp21788455p21848563.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
Re: ws-a questions
Posted by Adrian C <ad...@gmail.com>.
actually what I am saying about a difference in behaviour between JMS & HTTP
may be a red herring - we don't use CXF's JMS Config to receive messages (we
receive messages over JMS and then send them on a local transport) and as it
turns out we were discarding the SOAPAction on the JMS headers.
But other issues below still exist.
Adrian C wrote:
>
> Ok have some interesting findings here.
>
> For the sake of arguments image a ws with 2 operations create & delete and
> with corresponding soap actions.
>
> 1. With HTTP if there are conflicting SOAP actions the are caught - i.e.
> HTTP SOAPAction & WSA-SoapAction
> 2. If I specify a HTTP SOAP Action of create but the body of the soap
> request corresponds to a deleteRequest my create operation invoked is
> invoked!
> 3. If I specify a WSA SOAP Action of create but the body of the soap
> request
> corresponds to a deleteRequest my delete operation is invoked!
>
> What is the expected be behaviour here?
>
> I spotted this over JMS first - a client send in a request with a
> SOAPAction
> on the JMS headers that was at odds with wsa-soap action. I know that the
> SOAPAction as a header for JMS is not part of the spec, but the CXF client
> was population the JMS string property SOAPAction. So in this case it
> seems
> that there is a difference in behavior!
>
> Btw this is with CXF 2.1.3
>
> On Tue, Feb 3, 2009 at 6:12 PM, Daniel Kulp <dk...@apache.org> wrote:
>
>> On Mon February 2 2009 7:01:26 am Adrian C wrote:
>> > Hi,
>> >
>> > Can someone clarify how CXF works with WS-A? I had some unexpected
>> results
>> > where a client was calling our web services with two different SOAP
>> actions
>> > (one on the transport headers, http in this case, the other in the WSA
>> > headers).
>>
>> Hmm... That's not good. I checked the WS-Addressing code and the
>> validateIncomingMAPs method should be checking that the two actions are
>> equal
>> and throwing a fault if they aren't.
>>
>> Any chance you can hook up a debugger and make sure that method is
>> getting
>> called?
>>
>>
>> > The WS-A header as it turned out was incorrect however the
>> > correct operation was called? How can this be? I would have though the
>> the
>> > following would happen:
>> >
>> > 1. Check for ws-a headers & soap action there
>>
>> Technically, this SHOULD be irrelevant as the two actions should be
>> identical.
>> The check in MAPAggregator.validateIncomingMAPs should guarantee that.
>> The
>> first step is to make sure that is called.
>>
>> Dan
>>
>>
>> > 2. If no ws-a headers & soap action check for SOAP action in the
>> transport
>> > headers
>> > 3. If no action present use the contents of the SOAP:Body to determine
>> what
>> > operation to invoke.
>> >
>> > So can anyone clarify?
>> >
>> > Thanks.
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>
>
--
View this message in context: http://www.nabble.com/ws-a-questions-tp21788455p21848563.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: ws-a questions
Posted by Adrian Corcoran <ad...@gmail.com>.
Ok have some interesting findings here.
For the sake of arguments image a ws with 2 operations create & delete and
with corresponding soap actions.
1. With HTTP if there are conflicting SOAP actions the are caught - i.e.
HTTP SOAPAction & WSA-SoapAction
2. If I specify a HTTP SOAP Action of create but the body of the soap
request corresponds to a deleteRequest my create operation invoked is
invoked!
3. If I specify a WSA SOAP Action of create but the body of the soap request
corresponds to a deleteRequest my delete operation is invoked!
What is the expected be behaviour here?
I spotted this over JMS first - a client send in a request with a SOAPAction
on the JMS headers that was at odds with wsa-soap action. I know that the
SOAPAction as a header for JMS is not part of the spec, but the CXF client
was population the JMS string property SOAPAction. So in this case it seems
that there is a difference in behavior!
Btw this is with CXF 2.1.3
On Tue, Feb 3, 2009 at 6:12 PM, Daniel Kulp <dk...@apache.org> wrote:
> On Mon February 2 2009 7:01:26 am Adrian C wrote:
> > Hi,
> >
> > Can someone clarify how CXF works with WS-A? I had some unexpected
> results
> > where a client was calling our web services with two different SOAP
> actions
> > (one on the transport headers, http in this case, the other in the WSA
> > headers).
>
> Hmm... That's not good. I checked the WS-Addressing code and the
> validateIncomingMAPs method should be checking that the two actions are
> equal
> and throwing a fault if they aren't.
>
> Any chance you can hook up a debugger and make sure that method is getting
> called?
>
>
> > The WS-A header as it turned out was incorrect however the
> > correct operation was called? How can this be? I would have though the
> the
> > following would happen:
> >
> > 1. Check for ws-a headers & soap action there
>
> Technically, this SHOULD be irrelevant as the two actions should be
> identical.
> The check in MAPAggregator.validateIncomingMAPs should guarantee that.
> The
> first step is to make sure that is called.
>
> Dan
>
>
> > 2. If no ws-a headers & soap action check for SOAP action in the
> transport
> > headers
> > 3. If no action present use the contents of the SOAP:Body to determine
> what
> > operation to invoke.
> >
> > So can anyone clarify?
> >
> > Thanks.
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: ws-a questions
Posted by Daniel Kulp <dk...@apache.org>.
On Mon February 2 2009 7:01:26 am Adrian C wrote:
> Hi,
>
> Can someone clarify how CXF works with WS-A? I had some unexpected results
> where a client was calling our web services with two different SOAP actions
> (one on the transport headers, http in this case, the other in the WSA
> headers).
Hmm... That's not good. I checked the WS-Addressing code and the
validateIncomingMAPs method should be checking that the two actions are equal
and throwing a fault if they aren't.
Any chance you can hook up a debugger and make sure that method is getting
called?
> The WS-A header as it turned out was incorrect however the
> correct operation was called? How can this be? I would have though the the
> following would happen:
>
> 1. Check for ws-a headers & soap action there
Technically, this SHOULD be irrelevant as the two actions should be identical.
The check in MAPAggregator.validateIncomingMAPs should guarantee that. The
first step is to make sure that is called.
Dan
> 2. If no ws-a headers & soap action check for SOAP action in the transport
> headers
> 3. If no action present use the contents of the SOAP:Body to determine what
> operation to invoke.
>
> So can anyone clarify?
>
> Thanks.
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog