[ http://issues.apache.org/jira/browse/AXIS2-1457?page=all ]
Matt Lovett updated AXIS2-1457:
-------------------------------
Attachment: dispatch.patch
Here is a patch that moves the operation resolution out of
RequestURIBasedDispatcher and into a new one. I'll follow up with another patch
that modifies the axis2.xml files to include the new dispatcher.
> 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]
