On Nov 19, 2008, at 8:12 AM, Sergey Beryozkin wrote:
>
> I have two proposals for the next version of JAX-RS to address :
>
> 1. Introduce a composite context interface WebApplicationContext
>
> @Context WebApplicationContext
>
> for users be able to get HttpHeaders, UriInfo, SecurityContext, etc
> from WebApplicationContext, thus simplifying their code
>
We did have something along those lines in early sketches of the API
but went with the current arrangement instead. I don't see any really
compelling reason to introduce that kind of uber-context interface.
> 2. Introduce a message context interface MessageContext with a
> single method
>
> Object get(Object key)
>
> for users be able to retrieve properties which might've been set as
> hints either by the underlying JAX-RS implementation or filters. One
> can argue that in this case a user would actually write the
> unportable code but one could also say that products which use
> multiple JAX-RS implementations under the hood will ensure that the
> same code which relies on message properties not otherwise available
> in other JAX-RS contexts will be portable
>
> JAXWS provides similar context implementations
>
In the JAX-WS case there are standard handlers and the context is used
to pass information between individual handlers and between handlers
and SEI code. In the JAX-RS case we don't currently have any
equivalent to a JAX-WS handler so I'm not sure how useful a message
context would be.
It would seem more inline with the rest of the API for implementations
to define new injectable contexts.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.