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 <[email protected]> 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 <[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 > >> > > > > > > -- > 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. > >
