[ http://issues.apache.org/jira/browse/AXIS2-1457?page=comments#action_12444325 ] David Illsley commented on AXIS2-1457: --------------------------------------
I agree that separating out the dispatch of services and operations entirely is probably the cleanest solution to this problem. I've looked at all the dispatchers and it's my opinion that it's only really the RequestURIBasedDispatcher that needs to do findService() The others either do exactly the same thing with the To EPR or, in the case of the SOAPMessageBodyBasedDispatcher, parses the namespace of the SOAP Body element in the same fashion. I can't imagine that this EVER works? I'd therefore propose that we apply a patch similar to the one from Matt and then make the other findService() implemenations no-ops. > RequestURIBasedDispatcher incorrectly resolves the WS-RM operations > ------------------------------------------------------------------- > > Key: AXIS2-1457 > URL: http://issues.apache.org/jira/browse/AXIS2-1457 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: core > Reporter: Matt Lovett > Attachments: axisxml.patch, dispatch.patch > > > I have a testcase that is an async 2-way scenario, with Sandesha enabled. > Sending the request causes Sandesha to set up a CreateSequence message > targeted at the "To" address of the service, the RM handshake completes, and > the application request message goes out. When the other end generates the > response message Sandesha again creates a sequence, this time inbound to the > requester, using the "To" address of the reply message. As you would expect, > the "To" address is generated from the "ReplyTo" EPR in the request. > In my case the 2 addresses look like this: > Request To: "aixs2/services/RMSampleService" > Reply To: "axis2/services/anonService<uuid>/anonOutInOp" > As the CreateSequence message comes into the latter of these, the > RequestURIBasedDispatcher (wrongly) decides that we are targeting the > anonOutInOp, when the SOAPAction and Addressing dispatchers would have > identified the CreateSequence operation properly. With the current Sandesha > code this is not an issue, as the inbound Sandesha handlers intercept and > process the CreateSequence, ignoring the operation set in the message > context. I am trying to restructure Sandesha so that the message is > automatically routed to the Sandesha message receiver. Doing so will clean up > the flow through Sandesha, but does rely on accurate operation resolution. > I can see 2 ways to fix the issue: > - Stop attempting to identify the operation in the RequestURIBasedDispatcher > or > - Generate "ReplyTo" addresses that do not include the operation name > Patches for either of these are trivial, I'm happy to contribute them if > people can tell me their preferred option. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
