7 messages in net.java.dev.jax-ws.devRe: Propagation of FI content negotia...| From | Sent On | Attachments |
|---|---|---|
| Paul Sandoz | Jul 25, 2006 1:35 am | |
| Jiandong Guo | Jul 25, 2006 7:54 am | |
| Paul Sandoz | Jul 25, 2006 8:55 am | |
| Jiandong Guo | Jul 25, 2006 11:51 am | |
| Kohsuke Kawaguchi | Jul 25, 2006 12:08 pm | |
| Paul Sandoz | Jul 28, 2006 2:45 am | |
| Jiandong Guo | Jul 28, 2006 11:06 am |
| Subject: | Re: Propagation of FI content negotiation | |
|---|---|---|
| From: | Kohsuke Kawaguchi (Kohs...@Sun.COM) | |
| Date: | Jul 25, 2006 12:08:41 pm | |
| List: | net.java.dev.jax-ws.dev | |
The content negotiation is really more of a property of the entire pipeline, and not a property of a packet. So I think the proper solution is to eliminate the content negotiation property from Packet, and create a mechanism where a change to the pipeline (through request context) could be directly sent to the responsible pipes and codecs.
That would allow the FI codec to use the correct content negotiation propery without having the security code worry about FI, which just seems wrong.
Besides, if transport/codec specific details need to be captured on Packet, that sounds like an abstraction breakage.
This change would also allow some computation to be done when the property is set, to digest the value to the form more suitable for efficient processing, as opposed to wait until the last minute to do so (and end up doing so repeatedly.)
I think distributed property set is kinda close to what we need to do this.
Paul Sandoz wrote:
Hi,
As i understand it the secure conversation pipe creates a new Packet for its pipe line from the Packet of the client request. Are there any other cases where this occurs?
In the general case, should we propagate the content negotiation property? i.e.
private Packet(Packet that) { that.copySatelliteInto(this); this.invocationProperties = that.invocationProperties; this.handlerScopePropertyNames = that.handlerScopePropertyNames; this.contentNegotiation = that.contentNegotiation; // copy other properties that need to be copied. is there any? }
So in the case of secure conversation if the client enabled Fast Infoset then that would also get propagated to the secure conversation client.
Given that the 'pessimistic' property will only result in FI being enabled iff the service is FI-enabled the propagation of this property will not affect the interoperablity with non-FI-enabled secure conversation services.
Paul.
-- Kohsuke Kawaguchi Sun Microsystems kohs...@sun.com