Hi Stephan
> Hi Sergey,
>
> what kind of use case do you have in mind for the MessageContext interface? Perhaps you could give a code snippet.
a JAXRS runtime might be able to expose some internal things in the form of providers to a user.
Say, an execution context provider can be exposed and utilized by a user. Such providers will implement some interfaces. These
interfaces might get eventually standardized too to ensure the portability. For ex, in CXF we let users utilize transport-specific
support for suspended invocations. Arguably, HttpServletRequest could've been utilized too, but it would make the code for users
combinig JAXWS and JAXRS less portable, for ex, in cases where a service accepts SOAP requests over HTTP & JMS and HTTP requests
with the help of JAXRS.
Having a MessgeContext is better IMHO in cases like that.
Bill : I appreciate that WebBeans can be a good technology but my understanding that it's not necessarily the case it will be used
throughout the JAXRS code base. Judging from the replies to my email, I can guess at least one user will likely choose not to :-)
Thanks, Sergey
>
> best regards
> Stephan
>> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>
>