axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Lovett (JIRA)" <>
Subject [jira] Commented: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
Date Thu, 19 Oct 2006 15:22:37 GMT
    [ ] 
Matt Lovett commented on AXIS2-1457:

Hi Chamikara,

That sounds like a good solution, but will take a bit of pain, as I think that means editing
the axis2.xml files... and there are quite a few of them in the axis2 build tree! However,
if people like that approach I'm happy to write a script...

Here's a concrete proposal:

- Change the RequestURIBasedDispacther::findOperation() into a no-op
- Create a new RequestURIOerationDispatcher with a no-op findService(), and a real findOperation()
- Update the axis2.xml files to put the new dispactcher in after Addressing, in the Dispatch

Sound ok?


> RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
> -------------------------------------------------------------------
>                 Key: AXIS2-1457
>                 URL:
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: core
>            Reporter: Matt Lovett
> 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message