MessageContext Properties in Addressing reply.

[Jason Essington <ja...@GreenRiverComputing.com>]

Jarek, Dims,

I just ran into a bit of a snag with addressing.

I am using addressing along with wss4j. I am signing some of the 
addressing headers so the wss4j handler is after the addressing headers 
in the response (which is actually a new request because I am using 
replyTo)

So I have on the server side something like

server request chain
      wss4j handler
      addressing handler

server response chain
      addressing handler <-- this handler generates a new request for 
the response

[server side] client request chain <-- our server's response handling 
continues here
      addressing handler
      wss4j handler

Now, when we get to the wss4j handler that is suposed to sign and 
encrypt our response, it is getting all bitter and angry (throws an 
axis fault) ultimately because it can't find a message context property 
that was set during the server's request processing.

really this is a simple matter for me of just doing (in an overridden 
forwardMessage method)
       MessageContext msgContext = msg.getMessageContext();
       ...
       wssResults = (Vector) 
msgContext.getProperty(WSDoAllConstants.RECV_RESULTS);
       ...
       call.setProperty(WSDoAllConstants.RECV_RESULTS, wssResults);

What happens is that new Call() creates a new message context and every 
thing in the old one is pitched when we do call.setRequestMessage

I am sure there will be other instances where response handlers will 
need to have access to something previously set in the message context, 
so perhaps we should iterate over the properties in the old context and 
selectively add them to the new call so as not to break other handlers.

The main question I have is, are there some of the axis properties that 
we wouldn't want to replicate in the new call?

or maybe a better solution would be to add a couple of hooks to 
forwardMessage()

something like:
         Service service = getService();
         Call c = new Call(service);
         c.setTargetEndpointAddress(address.toString());
         c.setRequestMessage(msg);
         c.setProperty(Constants.ENV_ADDRESSING_REQUEST_HEADERS, 
headers);
         configureCall(c, msgContext);
         c.invoke();

...

protected Service getService()
{
     // override this method if you have a special way of obtaining a 
Service
     return new Service()
}

protected void configureCall(Call call, MessageContext oldCtx)
{
     // override this method if you have properties that need to be 
scavenged
     // from the old message context before the new call is invoked.
}

This way rather than wholesale copying of properties, custom 
implementations could simply move the properties they needed to the new 
call.

I would be happy to create a patch to accomplish this if you think it 
is a reasonable idea.

-jason

Re: MessageContext Properties in Addressing reply.

[Jason Essington <ja...@GreenRiverComputing.com>]

O.K. I made a report in jira along with a patch

	http://nagoya.apache.org/jira/browse/WSFX-20

-jason

On Jul 14, 2004, at 4:20 PM, Jason Essington wrote:

> Jarek, Dims,
>
> I just ran into a bit of a snag with addressing.
>
> I am using addressing along with wss4j. I am signing some of the 
> addressing headers so the wss4j handler is after the addressing 
> headers in the response (which is actually a new request because I am 
> using replyTo)
>
> So I have on the server side something like
>
> server request chain
>      wss4j handler
>      addressing handler
>
> server response chain
>      addressing handler <-- this handler generates a new request for 
> the response
>
> [server side] client request chain <-- our server's response handling 
> continues here
>      addressing handler
>      wss4j handler
>
> Now, when we get to the wss4j handler that is suposed to sign and 
> encrypt our response, it is getting all bitter and angry (throws an 
> axis fault) ultimately because it can't find a message context 
> property that was set during the server's request processing.
>
> really this is a simple matter for me of just doing (in an overridden 
> forwardMessage method)
>       MessageContext msgContext = msg.getMessageContext();
>       ...
>       wssResults = (Vector) 
> msgContext.getProperty(WSDoAllConstants.RECV_RESULTS);
>       ...
>       call.setProperty(WSDoAllConstants.RECV_RESULTS, wssResults);
>
> What happens is that new Call() creates a new message context and 
> every thing in the old one is pitched when we do 
> call.setRequestMessage
>
> I am sure there will be other instances where response handlers will 
> need to have access to something previously set in the message 
> context, so perhaps we should iterate over the properties in the old 
> context and selectively add them to the new call so as not to break 
> other handlers.
>
> The main question I have is, are there some of the axis properties 
> that we wouldn't want to replicate in the new call?
>
> or maybe a better solution would be to add a couple of hooks to 
> forwardMessage()
>
> something like:
>         Service service = getService();
>         Call c = new Call(service);
>         c.setTargetEndpointAddress(address.toString());
>         c.setRequestMessage(msg);
>         c.setProperty(Constants.ENV_ADDRESSING_REQUEST_HEADERS, 
> headers);
>         configureCall(c, msgContext);
>         c.invoke();
>
> ...
>
> protected Service getService()
> {
>     // override this method if you have a special way of obtaining a 
> Service
>     return new Service()
> }
>
> protected void configureCall(Call call, MessageContext oldCtx)
> {
>     // override this method if you have properties that need to be 
> scavenged
>     // from the old message context before the new call is invoked.
> }
>
> This way rather than wholesale copying of properties, custom 
> implementations could simply move the properties they needed to the 
> new call.
>
> I would be happy to create a patch to accomplish this if you think it 
> is a reasonable idea.
>
> -jason
>