Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Message-ID: <965487.1161271357447.JavaMail.jira@brutus>
Date: Thu, 19 Oct 2006 08:22:37 -0700 (PDT)
From: "Matt Lovett (JIRA)" <jira@apache.org>
To: axis-dev@ws.apache.org
Subject: [jira] Commented: (AXIS2-1457) RequestURIBasedDispatcher
 incorrectly resolves the WS-RM operations
In-Reply-To: <10321068.1161253054932.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org