You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Matt Lovett (JIRA)" <ji...@apache.org> on 2007/07/03 15:31:06 UTC
[jira] Created: (AXIS2-2892) Axis2 replyTo EPR is not stable
Axis2 replyTo EPR is not stable
-------------------------------
Key: AXIS2-2892
URL: https://issues.apache.org/jira/browse/AXIS2-2892
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: kernel
Reporter: Matt Lovett
Priority: Minor
This is an issue that cropped up while doing some interop testing with Sandesha, and .net. We were invoking serveral operations on a service, and were async-on-the-wire. The algorithm that the engine uses to choose the replyTo address includes the operation name, which means that the replyTo address changes from message to message.
The .net runtime doesn't like it when the replyTo changes... so the testcase failed. There doesn't seem to be any need to include the operation name in the replyTo, so it seemed simplest to ignore it, and build the replyTo based on the service name.
I'll attach a patch shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Commented: (AXIS2-2892) Axis2 replyTo EPR is not stable
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12509931 ]
Davanum Srinivas commented on AXIS2-2892:
-----------------------------------------
Fixed in svn revision 552905
thanks,
dims
> Axis2 replyTo EPR is not stable
> -------------------------------
>
> Key: AXIS2-2892
> URL: https://issues.apache.org/jira/browse/AXIS2-2892
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: kernel
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: reply.patch
>
>
> This is an issue that cropped up while doing some interop testing with Sandesha, and .net. We were invoking serveral operations on a service, and were async-on-the-wire. The algorithm that the engine uses to choose the replyTo address includes the operation name, which means that the replyTo address changes from message to message.
> The .net runtime doesn't like it when the replyTo changes... so the testcase failed. There doesn't seem to be any need to include the operation name in the replyTo, so it seemed simplest to ignore it, and build the replyTo based on the service name.
> I'll attach a patch shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-2892) Axis2 replyTo EPR is not stable
Posted by "Matt Lovett (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Lovett updated AXIS2-2892:
-------------------------------
Attachment: reply.patch
Patch as described above
> Axis2 replyTo EPR is not stable
> -------------------------------
>
> Key: AXIS2-2892
> URL: https://issues.apache.org/jira/browse/AXIS2-2892
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: kernel
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: reply.patch
>
>
> This is an issue that cropped up while doing some interop testing with Sandesha, and .net. We were invoking serveral operations on a service, and were async-on-the-wire. The algorithm that the engine uses to choose the replyTo address includes the operation name, which means that the replyTo address changes from message to message.
> The .net runtime doesn't like it when the replyTo changes... so the testcase failed. There doesn't seem to be any need to include the operation name in the replyTo, so it seemed simplest to ignore it, and build the replyTo based on the service name.
> I'll attach a patch shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-2892) Axis2 replyTo EPR is not stable
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-2892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas resolved AXIS2-2892.
-------------------------------------
Resolution: Fixed
> Axis2 replyTo EPR is not stable
> -------------------------------
>
> Key: AXIS2-2892
> URL: https://issues.apache.org/jira/browse/AXIS2-2892
> Project: Axis 2.0 (Axis2)
> Issue Type: Improvement
> Components: kernel
> Reporter: Matt Lovett
> Priority: Minor
> Attachments: reply.patch
>
>
> This is an issue that cropped up while doing some interop testing with Sandesha, and .net. We were invoking serveral operations on a service, and were async-on-the-wire. The algorithm that the engine uses to choose the replyTo address includes the operation name, which means that the replyTo address changes from message to message.
> The .net runtime doesn't like it when the replyTo changes... so the testcase failed. There doesn't seem to be any need to include the operation name in the replyTo, so it seemed simplest to ignore it, and build the replyTo based on the service name.
> I'll attach a patch shortly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org