dev@jax-ws.java.net

Re: Propagation of properties from RequestContext context to Packet

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Wed, 05 Apr 2006 11:00:49 +0200

Kohsuke Kawaguchi wrote:
>> I am implementing support for FI content negotiation and would like to
>> know what is the best way is to propagate the conneg property on the
>> request context to the packet.
>
>
> I think this is touching a deep issue, of how to allow applications to
> configure pipes through a proxy. This is really a very generic problem
> that will happen to any non-trivial pipe.
>
> For example, HTTP transport might want to allow users to set a proxy
> authentication information, security might want to let people change the
> keystore (I'm just making this one up), and so on.
>
> These configurations aren't really a "packet" property. There really is
> no need for those values to be passed around between pipes. It only
> needs to be delivered to a particular pipe that it's intended to.
> Besides, attaching them to Packet is not good for performance, because:
>
> - Stub has to always copy values from request context to Packet
> - Pipes have to check for them all the time
>
> It seems to me that a better approach is to somehow allow pipes to
> expose properties to RequestContext directly, in such a way that the act
> of setting it would immediately call the corresponding method on the
> corresponding pipe (as opposed to values set to Packet, to be picked up
> by a pipe)
>
> A downside is that it interacts with asynchronous invocations (changing
> a property while asynchronous invocation is in progress may affect that
> invocation, while ideally it shouldn't.) I know that the spec-defined
> properties must observe this carefully, but I think we can do this for
> many proprietary properties, such as FI content negotiation.
>

I agree.

It would be better if pipes can get access to properties directly
associated with the production of an outbound message that are constant
with respect to the outbound message (represented as a Packet) as it
flows through the pipeline.

Is the request context instance guaranteed to be the same for the
lifetime of the pipe line? If so could the client pipes can obtain the
com.sun.xml.ws.client.RequestContent from a method on the WSBinding
interface or the BindingID abstract class?

Paul.

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109