[jira] Created: (AXIS2-1118) Off by one error in SOAP 1.2 action processing
Off by one error in SOAP 1.2 action processing
--
Key: AXIS2-1118
URL: http://issues.apache.org/jira/browse/AXIS2-1118
Project: Apache Axis 2.0 (Axis2)
Issue Type: Bug
Components: transports
Reporter: Matt Lovett
Priority: Minor
While debugging a failing Sandesha unit test (the SOAPVersionTest), I was
getting failures to do with soap action mismatches. I've tracked the defect to
the following code in HTTPTransportUtils, around line 216:
String transientString =
contentType.substring(index, contentType.length());
int equal = transientString.indexOf("=");
int firstSemiColon = transientString.indexOf(";");
String soapAction; // This will contain "" in the
string
if (firstSemiColon > -1) {
soapAction = transientString.substring(equal +
1, firstSemiColon - 1);
In my case with the string like: action="";
The substring cuts one too far, setting soapAction to: "
Note there is no trailing " any more, which then messes up the code that
attempts to trim quotes off
each end of the string.
The fix is trivial:
-soapAction = transientString.substring(equal +
1, firstSemiColon - 1);
+soapAction = transientString.substring(equal +
1, firstSemiColon);
Thanks
Matt
--
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]
[jira] Created: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
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/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]
[jira] Commented: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
[ 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/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]
[jira] Updated: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
[ http://issues.apache.org/jira/browse/AXIS2-1457?page=all ] Matt Lovett updated AXIS2-1457: --- Attachment: dispatch.patch Here is a patch that moves the operation resolution out of RequestURIBasedDispatcher and into a new one. I'll follow up with another patch that modifies the axis2.xml files to include the new dispatcher. > 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 > 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/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]
[jira] Updated: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
[ http://issues.apache.org/jira/browse/AXIS2-1457?page=all ] Matt Lovett updated AXIS2-1457: --- Attachment: axisxml.patch Here is the second patch, which plus the new dispatcher into the axis2.xml files. > 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 > 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/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]
[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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2892) Axis2 replyTo EPR is not stable
[ 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-1764) Improve trace for the Handler.InvocationResponse class
Improve trace for the Handler.InvocationResponse class -- Key: AXIS2-1764 URL: http://issues.apache.org/jira/browse/AXIS2-1764 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Reporter: Matt Lovett Priority: Minor Attachments: trace.patch When handlers return instances of the InvocationResponse, it is not immediately clear what the response was, as the toString method hasn't been implemented. I'll attach a patch to add toString, so that we get better trace. -- 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]
[jira] Updated: (AXIS2-1764) Improve trace for the Handler.InvocationResponse class
[ http://issues.apache.org/jira/browse/AXIS2-1764?page=all ] Matt Lovett updated AXIS2-1764: --- Attachment: trace.patch Patch as described > Improve trace for the Handler.InvocationResponse class > -- > > Key: AXIS2-1764 > URL: http://issues.apache.org/jira/browse/AXIS2-1764 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel >Reporter: Matt Lovett >Priority: Minor > Attachments: trace.patch > > > When handlers return instances of the InvocationResponse, it is not > immediately clear what the response was, as the toString method hasn't been > implemented. I'll attach a patch to add toString, so that we get better trace. -- 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]
[jira] Created: (AXIS2-1870) Enable the WS-RM anonymous URI template
Enable the WS-RM anonymous URI template --- Key: AXIS2-1870 URL: http://issues.apache.org/jira/browse/AXIS2-1870 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: Addressing, kernel Reporter: Matt Lovett Priority: Minor The WS-RM 1.1 spec (at the Public Review level) defines a URI template that has behaviour similar to the WS-A anon uri. I have recently been making changes to Sandesha to support this, and need some base axis changes to handle the new URI. I'll attach the most basic way of fixing the issues, but we might want to define a more general mechanism so that modules can plug in capabilities like this when they are engaged. -- 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]
[jira] Updated: (AXIS2-1870) Enable the WS-RM anonymous URI template
[ http://issues.apache.org/jira/browse/AXIS2-1870?page=all ] Matt Lovett updated AXIS2-1870: --- Attachment: axis2-RM2way.patch Patch as described above. Also see https://issues.apache.org/jira/browse/SANDESHA2-62 > Enable the WS-RM anonymous URI template > --- > > Key: AXIS2-1870 > URL: http://issues.apache.org/jira/browse/AXIS2-1870 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel, Addressing >Reporter: Matt Lovett >Priority: Minor > Attachments: axis2-RM2way.patch > > > The WS-RM 1.1 spec (at the Public Review level) defines a URI template that > has behaviour similar to the WS-A anon uri. I have recently been making > changes to Sandesha to support this, and need some base axis changes to > handle the new URI. > I'll attach the most basic way of fixing the issues, but we might want to > define a more general mechanism so that modules can plug in capabilities like > this when they are engaged. -- 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]
[jira] Created: (AXIS2-1972) Enable Sandesha to control reliable sync 2-way clients
Enable Sandesha to control reliable sync 2-way clients -- Key: AXIS2-1972 URL: https://issues.apache.org/jira/browse/AXIS2-1972 Project: Apache Axis 2.0 (Axis2) Issue Type: Improvement Components: kernel Reporter: Matt Lovett Attachments: sync2WayAxis.patch As described in Sandesha2 JIRA https://issues.apache.org/jira/browse/SANDESHA2-64, we currently have a problem configuring clients that want to do sync 2-way messaging using WS-RM. It would be nice to allow the Sandesha module to take care of the configuration for them, so that the client code doesn't need to change when we engage the Sandesha module. The solution I am proposing is to add a new configuration constant, which the operation and service clients can check for. In the special case where are are doing sync 2-way, and this option is present, then we setup a callback object. The Sandesha module then drives the response message back through the axis engine, and triggers the callback, which can then return to the application. This code is very similar to, but not quite the same as USE_CUSTOM_LISTENER. I think that option was introduced for Sandesha too, but doesn't seem to be used. Once we add in the new option that I need I'd be happy to supply a second patch to remove or deprecate that option, if people would like me to. I'll attach a patch that implements the Axis2 half of the changes I need. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Updated: (AXIS2-1972) Enable Sandesha to control reliable sync 2-way clients
[ https://issues.apache.org/jira/browse/AXIS2-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Lovett updated AXIS2-1972: --- Attachment: sync2WayAxis.patch > Enable Sandesha to control reliable sync 2-way clients > -- > > Key: AXIS2-1972 > URL: https://issues.apache.org/jira/browse/AXIS2-1972 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel >Reporter: Matt Lovett > Attachments: sync2WayAxis.patch > > > As described in Sandesha2 JIRA > https://issues.apache.org/jira/browse/SANDESHA2-64, we currently have a > problem configuring clients that want to do sync 2-way messaging using WS-RM. > It would be nice to allow the Sandesha module to take care of the > configuration for them, so that the client code doesn't need to change when > we engage the Sandesha module. > The solution I am proposing is to add a new configuration constant, which the > operation and service clients can check for. In the special case where are > are doing sync 2-way, and this option is present, then we setup a callback > object. The Sandesha module then drives the response message back through the > axis engine, and triggers the callback, which can then return to the > application. > This code is very similar to, but not quite the same as USE_CUSTOM_LISTENER. > I think that option was introduced for Sandesha too, but doesn't seem to be > used. Once we add in the new option that I need I'd be happy to supply a > second patch to remove or deprecate that option, if people would like me to. > I'll attach a patch that implements the Axis2 half of the changes I need. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
[jira] Created: (AXIS2-2020) JAX-WS clients using sync-2-way and RM fail
JAX-WS clients using sync-2-way and RM fail --- Key: AXIS2-2020 URL: https://issues.apache.org/jira/browse/AXIS2-2020 Project: Apache Axis 2.0 (Axis2) Issue Type: Bug Components: jaxws, kernel Reporter: Matt Lovett Attachments: opClient.patch Hi all, I have been doing some testing with jax-ws applications with Sandesha engaged, and I hit an issue with sync-2-way messaging. The axis ServiceClient and OutInOperationClient have some logic to force the invocation down the async path, which is what is needed in this case. (The addition of RM into the mix effectively makes the invocation async, even though we are using synchronous comms). Unfortunately, the jax-ws layer calls into the OutInOperationClient, and bypasses the logic in the ServiceClient. The same issue would apply to any other component that chooses to use the operation client directly. My suggested fix is to push some of the logic that is currently in the ServiceClient down into the operation client. I'll attach a patch soon, but the basic idea is to move the SyncCallBack class down. Thanks, Matt -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2020) JAX-WS clients using sync-2-way and RM fail
[ https://issues.apache.org/jira/browse/AXIS2-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Lovett updated AXIS2-2020: --- Attachment: opClient.patch Here's a patch that resolves the issue for me. It's relative to the modules/kernel directory within the axis2 tree. > JAX-WS clients using sync-2-way and RM fail > --- > > Key: AXIS2-2020 > URL: https://issues.apache.org/jira/browse/AXIS2-2020 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws, kernel >Reporter: Matt Lovett > Attachments: opClient.patch > > > Hi all, > I have been doing some testing with jax-ws applications with Sandesha > engaged, and I hit an issue with sync-2-way messaging. The axis ServiceClient > and OutInOperationClient have some logic to force the invocation down the > async path, which is what is needed in this case. (The addition of RM into > the mix effectively makes the invocation async, even though we are using > synchronous comms). Unfortunately, the jax-ws layer calls into the > OutInOperationClient, and bypasses the logic in the ServiceClient. The same > issue would apply to any other component that chooses to use the operation > client directly. > My suggested fix is to push some of the logic that is currently in the > ServiceClient down into the operation client. I'll attach a patch soon, but > the basic idea is to move the SyncCallBack class down. > Thanks, Matt -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AXIS2-2020) JAX-WS clients using sync-2-way and RM fail
[ https://issues.apache.org/jira/browse/AXIS2-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Lovett updated AXIS2-2020: --- Attachment: opClient2.patch Updated patch that resolves some merge conflicts, and pulls in better error & timeout handling that was added to the service client. > JAX-WS clients using sync-2-way and RM fail > --- > > Key: AXIS2-2020 > URL: https://issues.apache.org/jira/browse/AXIS2-2020 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws, kernel >Reporter: Matt Lovett > Attachments: opClient.patch, opClient2.patch > > > Hi all, > I have been doing some testing with jax-ws applications with Sandesha > engaged, and I hit an issue with sync-2-way messaging. The axis ServiceClient > and OutInOperationClient have some logic to force the invocation down the > async path, which is what is needed in this case. (The addition of RM into > the mix effectively makes the invocation async, even though we are using > synchronous comms). Unfortunately, the jax-ws layer calls into the > OutInOperationClient, and bypasses the logic in the ServiceClient. The same > issue would apply to any other component that chooses to use the operation > client directly. > My suggested fix is to push some of the logic that is currently in the > ServiceClient down into the operation client. I'll attach a patch soon, but > the basic idea is to move the SyncCallBack class down. > Thanks, Matt -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-2020) JAX-WS clients using sync-2-way and RM fail
[ https://issues.apache.org/jira/browse/AXIS2-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12469063 ] Matt Lovett commented on AXIS2-2020: The patch went in a few days ago: http://svn.apache.org/viewvc?view=rev&revision=499521 > JAX-WS clients using sync-2-way and RM fail > --- > > Key: AXIS2-2020 > URL: https://issues.apache.org/jira/browse/AXIS2-2020 > Project: Axis 2.0 (Axis2) > Issue Type: Bug > Components: jaxws, kernel >Reporter: Matt Lovett > Assigned To: Deepal Jayasinghe > Attachments: opClient.patch, opClient2.patch > > > Hi all, > I have been doing some testing with jax-ws applications with Sandesha > engaged, and I hit an issue with sync-2-way messaging. The axis ServiceClient > and OutInOperationClient have some logic to force the invocation down the > async path, which is what is needed in this case. (The addition of RM into > the mix effectively makes the invocation async, even though we are using > synchronous comms). Unfortunately, the jax-ws layer calls into the > OutInOperationClient, and bypasses the logic in the ServiceClient. The same > issue would apply to any other component that chooses to use the operation > client directly. > My suggested fix is to push some of the logic that is currently in the > ServiceClient down into the operation client. I'll attach a patch soon, but > the basic idea is to move the SyncCallBack class down. > Thanks, Matt -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-2147) Class cast exception due to overloaded use of a constant
Class cast exception due to overloaded use of a constant
Key: AXIS2-2147
URL: https://issues.apache.org/jira/browse/AXIS2-2147
Project: Axis 2.0 (Axis2)
Issue Type: Bug
Components: kernel
Reporter: Matt Lovett
When using Sandesha, messages may be retransmitted. When running the unit tests
that exercise this, we are getting a
class cast exception the second time that we send a message. Here's the java
stack trace:
10943 [Axis2 Task] ERROR org.apache.sandesha2.workers.SenderWorker - Sandesha2
got an exception when sending a message: java.lang.ClassCastException:
org.apache.commons.httpclient.methods.PostMethod incompatible with
java.lang.String.
java.lang.ClassCastException: org.apache.commons.httpclient.methods.PostMethod
incompatible with java.lang.String
at
org.apache.axis2.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:48)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:349)
at
org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:208)
at org.apache.axis2.engine.AxisEngine.resumeSend(AxisEngine.java:383)
at org.apache.sandesha2.workers.SenderWorker.run(SenderWorker.java:228)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:788)
The code that is executing is the cast to String of 'httpMethod'
public void send(MessageContext msgContext, OMElement dataout, URL url,
String soapActionString)
throws MalformedURLException, AxisFault, IOException {
// execute the HtttpMethodBase - a connection manager can be given for
// handle multiple
String httpMethod =
(String)
msgContext.getProperty(Constants.Configuration.HTTP_METHOD);
if ((httpMethod != null)
&&
Constants.Configuration.HTTP_METHOD_GET.equalsIgnoreCase(httpMethod)) {
this.sendViaGet(msgContext, url, soapActionString);
return;
}
this.sendViaPost(msgContext, dataout, url, soapActionString);
}
I think the root cause is probably due to two contstants having the same value,
and both being used as keys into the MessageContext properties:
org.apache.axis2.transport.http.HTTPConstants.HTTP_METHOD = "HTTP_METHOD"
and
org.apache.axis2.Constants.Configuration.HTTP_METHOD = "HTTP_METHOD"
I think that the HTTPConstants one is written part way through the first send,
making a side-effect that poisons the second send. This is when using Sandesha
without calling the MessageContext serialization code, persumably if we were
using that we would avoid the issue.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (AXIS2-2191) Dispatch phase optimizations can prevent Sandesha from using the back-channel for acks
Dispatch phase optimizations can prevent Sandesha from using the back-channel for acks -- Key: AXIS2-2191 URL: https://issues.apache.org/jira/browse/AXIS2-2191 Project: Axis 2.0 (Axis2) Issue Type: Bug Components: kernel Reporter: Matt Lovett Chamikara and I have been disussing this issue on the sandesha-dev list. Essentially there is code in the DispatchPhase (around line 71) that sends a HTTP 202 back if the message is 1-way, or if it is 2-way with an async replyTo. However, there are cases when the WS-RM layer needs to write a SequenceAck message into the backchannel, and this code is running before we get the chance to try. We cannot move our logic earlier, as we need the dispatch phase to have resolved the MEP before we can make the decision. The only way forward we can see is to define a new constant, and avoid the code in DispatchPhase when the constant is set. When RM is enabled we will set the value onto the ConfigurationContext at the time that Sandesha is engaged. From then on the Sandesha handlers will take the responsibility - returning the HTTP 202 as soon as possible if we do not need the backchannel. Here's a proposal for the new constant name: // If this property is set to Boolean.TRUE then the Dispatch Phase should not try so send an early // transport-level ack back. Downstream handlers are expected to send an transport-level ack as // soon as they are sure that the transport level ack may be sent. org.apache.axis2.Constants.Configuration.DEFER_TRANSPORT_ACKNOWLEDGEMENT = "deferTransportAcks"; -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1972) Enable Sandesha to control reliable sync 2-way clients
[ https://issues.apache.org/jira/browse/AXIS2-1972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Lovett resolved AXIS2-1972. Resolution: Fixed > Enable Sandesha to control reliable sync 2-way clients > -- > > Key: AXIS2-1972 > URL: https://issues.apache.org/jira/browse/AXIS2-1972 > Project: Axis 2.0 (Axis2) > Issue Type: Improvement > Components: kernel >Reporter: Matt Lovett > Assigned To: David Illsley > Attachments: sync2WayAxis.patch > > > As described in Sandesha2 JIRA > https://issues.apache.org/jira/browse/SANDESHA2-64, we currently have a > problem configuring clients that want to do sync 2-way messaging using WS-RM. > It would be nice to allow the Sandesha module to take care of the > configuration for them, so that the client code doesn't need to change when > we engage the Sandesha module. > The solution I am proposing is to add a new configuration constant, which the > operation and service clients can check for. In the special case where are > are doing sync 2-way, and this option is present, then we setup a callback > object. The Sandesha module then drives the response message back through the > axis engine, and triggers the callback, which can then return to the > application. > This code is very similar to, but not quite the same as USE_CUSTOM_LISTENER. > I think that option was introduced for Sandesha too, but doesn't seem to be > used. Once we add in the new option that I need I'd be happy to supply a > second patch to remove or deprecate that option, if people would like me to. > I'll attach a patch that implements the Axis2 half of the changes I need. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2-1457) RequestURIBasedDispatcher incorrectly resolves the WS-RM operations
[ https://issues.apache.org/jira/browse/AXIS2-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Lovett resolved AXIS2-1457. Resolution: Fixed > RequestURIBasedDispatcher incorrectly resolves the WS-RM operations > --- > > Key: AXIS2-1457 > URL: https://issues.apache.org/jira/browse/AXIS2-1457 > Project: 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/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. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
