[ 
http://issues.apache.org/jira/browse/AXIS2-1457?page=comments#action_12443551 ] 
            
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 phase

Sound ok?

Matt


> 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
>
> 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]

Reply via email to