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 <[email protected]> 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 > > [email protected] > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
