[jira] Commented: (AXIS2-242) A client side handler in the response(in) flow cannot access the request(out) message context

["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