[
https://issues.apache.org/jira/browse/AXIS2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Lovett resolved AXIS2-1457.
--------------------------------
Resolution: Fixed
> RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
> -------------------------------------------------------------------
>
> Key: AXIS2-1457
> URL: https://issues.apache.org/jira/browse/AXIS2-1457
> Project: 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.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
