[ http://issues.apache.org/jira/browse/AXIS2-1457?page=comments#action_12443993 ] Chamikara Jayalath commented on AXIS2-1457: -------------------------------------------
Hi Chinthaka, Matt, I think that should be the ideal solution. Service Dispatching and Operation dispatching are two different things. And users may need to interleave these. Also I belive that the default axis2.xml configuration we provide has to support most of the scenarios. From what I see upto now (basically from security and RM perspectives) it seemed to me like the following order (on which the Matt had sent his patch) seems to be the correct one. 1. RequestURIBased service dispatching 2. AddressingBased service and operation dispatching 3. RequestURIBased operation diepatching. Will this order support other scenarios as well. If it doesnt what is the default order of dispatchers we should be providing. I think it will be a real pain for the users if we ask them to configure the order of dispatchers themselves. Chamikara > 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]
