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 "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org> on 2005/09/24 17:19:28 UTC
[jira] Created: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context
A client side handler in the response(in) flow cannot access the request(out) message context
---------------------------------------------------------------------------------------------
Key: AXIS2-242
URL: http://issues.apache.org/jira/browse/AXIS2-242
Project: Apache Axis 2.0 (Axis2)
Type: Bug
Reporter: Ruchith Udayanga Fernando
Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
In the above instances the we can access the operation context from the message context in the inflow with:
OperationContext opCtx = msgContext.getOperationContext();
but both 'inMessageContext' and 'outMessageContext' references were null.
I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
What do u folks think about this?
--
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
[jira] Commented: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-242?page=comments#action_12330388 ]
Ruchith Udayanga Fernando commented on AXIS2-242:
-------------------------------------------------
But what about the situation when we don't use addressing? In that case we endup creating a new operation context each time a response message reaches the client (This is te way we have it now).
Therefore as in the original comment we don't have the message contexts because we are creating a new operation context in the InstanceDispatcher.
> A client side handler in the response(in) flow cannot access the request(out) message context
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-242
> URL: http://issues.apache.org/jira/browse/AXIS2-242
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Reporter: Ruchith Udayanga Fernando
>
> Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
> In the above instances the we can access the operation context from the message context in the inflow with:
> OperationContext opCtx = msgContext.getOperationContext();
> but both 'inMessageContext' and 'outMessageContext' references were null.
> I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
> The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
> What do u folks think about this?
--
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
[jira] Commented: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-242?page=comments#action_12330937 ]
Ruchith Udayanga Fernando commented on AXIS2-242:
-------------------------------------------------
Fixed this problem for the blocking case.
Several instances of msgContext.setOperationContext(operationContext); was replaced by operationDesc.registerOperationContext(msgCtx,opCtx) where it adds the message context into the operation context as well.
We'll still have to check the non-blocking scenario.
> A client side handler in the response(in) flow cannot access the request(out) message context
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-242
> URL: http://issues.apache.org/jira/browse/AXIS2-242
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Reporter: Ruchith Udayanga Fernando
>
> Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
> In the above instances the we can access the operation context from the message context in the inflow with:
> OperationContext opCtx = msgContext.getOperationContext();
> but both 'inMessageContext' and 'outMessageContext' references were null.
> I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
> The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
> What do u folks think about this?
--
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
[jira] Commented: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context
Posted by "Sanjiva Weerawarana (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-242?page=comments#action_12330387 ]
Sanjiva Weerawarana commented on AXIS2-242:
-------------------------------------------
But that's the correct behavior .. if there is no RelatesTo then there's no existing operation context.
Going back to your original comment, it should not be the case that msgContext.getOperationContext() != null and the resulting operationContext does not have any message contexts in it!
> A client side handler in the response(in) flow cannot access the request(out) message context
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-242
> URL: http://issues.apache.org/jira/browse/AXIS2-242
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Reporter: Ruchith Udayanga Fernando
>
> Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
> In the above instances the we can access the operation context from the message context in the inflow with:
> OperationContext opCtx = msgContext.getOperationContext();
> but both 'inMessageContext' and 'outMessageContext' references were null.
> I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
> The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
> What do u folks think about this?
--
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
[jira] Commented: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-242?page=comments#action_12330384 ]
Ruchith Udayanga Fernando commented on AXIS2-242:
-------------------------------------------------
The InstanceDispatcher is looking for the operation context using OperationDescription.findForExistingOperationContext and it will not find the operation context since addressing information is not available because it depends on the availability of RelatesTo.
public OperationContext findForExistingOperationContext(MessageContext msgContext) throws AxisFault {
OperationContext operationContext = null;
if (null == msgContext.getRelatesTo()) {
return null;
}
.....
.....
.....
}
The scenario I'm concerned about doesn't use addressing and the InstanceDispatcher cannot find the operation context and it creates a new one. Hence we cannot access the mesage context of the request flow
> A client side handler in the response(in) flow cannot access the request(out) message context
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-242
> URL: http://issues.apache.org/jira/browse/AXIS2-242
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Reporter: Ruchith Udayanga Fernando
>
> Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
> In the above instances the we can access the operation context from the message context in the inflow with:
> OperationContext opCtx = msgContext.getOperationContext();
> but both 'inMessageContext' and 'outMessageContext' references were null.
> I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
> The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
> What do u folks think about this?
--
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
[jira] Resolved: (AXIS2-242) A client side handler in the
response(in) flow cannot access the request(out) message context
Posted by "Ruchith Udayanga Fernando (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/AXIS2-242?page=all ]
Ruchith Udayanga Fernando resolved AXIS2-242:
---------------------------------------------
Resolution: Fixed
> A client side handler in the response(in) flow cannot access the request(out) message context
> ---------------------------------------------------------------------------------------------
>
> Key: AXIS2-242
> URL: http://issues.apache.org/jira/browse/AXIS2-242
> Project: Apache Axis 2.0 (Axis2)
> Type: Bug
> Reporter: Ruchith Udayanga Fernando
>
> Seems like its not possible to access the out message context of a web service invocation, from an inflow handler placed in the Dispatch or PostDispatch phases. - I experienced this with a blocking in-out message on a single channel.
> In the above instances the we can access the operation context from the message context in the inflow with:
> OperationContext opCtx = msgContext.getOperationContext();
> but both 'inMessageContext' and 'outMessageContext' references were null.
> I ran into this problem when updating the security module, where we have to communicate the signature 'values' of the outgoing message to the handler in the inflow to verify against the values sent in the wsse11:SignatureConfirmation element.
> The workaround used for this situation is to have a ThreadLocal reference in a util class to hold the values set by the outflow handler (WSDoAllSender) and to be picked up by the inflow handler (WSDoAllReceiver)
> What do u folks think about this?
--
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