axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Illsley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
Date Fri, 27 Oct 2006 07:36:17 GMT
    [ http://issues.apache.org/jira/browse/AXIS2-1457?page=comments#action_12445104 ] 
            
David Illsley commented on AXIS2-1457:
--------------------------------------

I committed slight modifications of these patches to trunk a couple of days ago.
I included AXIS2-1457 in the first line of the commit but it's not appearing on the page,
presumably because of the infra changes

> 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: 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.
-
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


Mime
View raw message