Kohsuke Kawaguchi wrote:
>
> (Bundling up replies to multiple e-mails)
>
> Paul Sandoz wrote:
>
>> 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?
>
>
> I think what I have in my mind is not to store values in
> RequestContent --- that would require each pipe to check for the
> values, and check often, because pipes don't know when they change.
>
> Instead, I think it would be good if the user invocation of
> RequestContext.put(SOMETHING,value); eventually invokes
> SomePipe.setSomething(value); We do early hand-shaking among pipes and
> stub to make this possible.
>
> In this way, values are injected into your pipe when they changed, so
> by the time you see a message, you have all you need prepared and
> pre-computed around (as opposed to check Packet.invocationProperties
> or etc.)
>
> We need something similar for injecting HTTP related properties into
> WebServiceContext on the server side, so this shoots down two birds.
Yes. Otherwise, other components start using
packet.invocationProperties.get(SERVLET_CONTEXT). I thought we would do
create a wrapper for value, not for property name.
For e.g:
RequestContext.put(HTTP_HEADERS, SOMETHING) for standard properties.
Since our runtime knows about SOMETHING, we use it to compute value for
that property lazily. SOMETHING could be
interface SOMETHING<T> {
T getValue()
}
But it could be a problem if the class wants to expose multiple properties.
>
>
>> I wish i could pop over to Santa Clara and have a white board session
>> on this with you :-)
>
>
> Yes. In fact, I think I'm going to ask people that we really need to
> have you come over here, if just for a week. If nothing else, it would
> be really really great if you can come here a week before for JavaOne,
> or a week after JavaOne, so that we can have concentrated time talking
> about all the issues.
>
>
>> I think the conneg property would be directly associated with the
>> HTTP transport pipe, and my plan was to manage the conneg state on
>> this pipe.
>
>
> Does FI interact with HTTP? Is that because you use Accept (or some
> other HTTP) header? Does that mean FI can be only used with HTTP?
> Decoder takes a Packet, which contains transport-specific information
> in it. Can you get to Accept header from it?
>
> I think it would be nice to keep the transport and the encoder separate.
I think so. FI's content negotiation is based on HTTP headers and except
that it doesn't depend on HTTP(The encoding itself doesn't depend on HTTP).
>> If the encoder facade is used how can the transport inform the facade
>> to encode using the FI encoder?
>
>
> For the above reason I really don't want the transport to choose which
> encoding it uses.
EncoderFacade can see from transport headers and pick FI encoder.
Jitu