[
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
