[ http://issues.apache.org/jira/browse/AXIS2-1457?page=comments#action_12445104 ] David Illsley commented on AXIS2-1457: --------------------------------------
I committed slight modifications of these patches to trunk a couple of days ago. I included AXIS2-1457 in the first line of the commit but it's not appearing on the page, presumably because of the infra changes > 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: kernel > Reporter: Matt Lovett > Assigned To: David Illsley > 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]
