On 9/7/2012 10:30 AM, Sergey Beryozkin wrote:
> On 07/09/12 14:22, Bill Burke wrote:
>>
>>
>> On 9/7/2012 7:53 AM, Markus KARG wrote:
>>>> -----Original Message-----
>>>> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
>>>> Sent: Freitag, 7. September 2012 11:37
>>>> To: jsr339-experts_at_jax-rs-spec.java.net
>>>> Subject: [jsr339-experts] Binding of ContainerRequestContext to Servlet
>>>>
>>>> The documentation for all the ContainerRequestContext methods to do
>>>> with retrieving or setting the properties refers to Servlet
>>>> (effectively
>>>> HttpServletRequest) attributes.
>>>>
>>>> getPropertyNames() even returns Enumeration.
>>>>
>>>> This concerns me a bit. I think if some users are keen to work with
>>>> Servlet API in context of JAX-RS then they will expect more than just
>>>> the ability to get an access to the underlying Servlet attributes. In
>>>> other words, they'd want HTTPServletRequest.
>>>>
>>>> AFAIK, the whole idea was to be able to exchange properties between the
>>>> filters, as such I do not see why Servlet even has to be mentioned, and
>>>> the ancient legacy Enumeration interface has to be introduced into the
>>>> signature.
>>>>
>>>> It also may send a message that JAX-RS is some kind of thin wrapper on
>>>> top of Servlet API.
>>>>
>>>> Thoughts ?
>>>>
>>>> Cheers, Sergey
>>>
>>> I also think that the JAX-RS API should not be too Servlet API
>>> related. If a
>>> container is not using Servlet at all (what might become more and more
>>> essential in future, when platforms turn from Web Hosting Cluster to
>>> Application Clouds), there should be no need for the implementor to
>>> provide
>>> a Servlet API class. This has some kind of design smell ("We all base on
>>> Servlet API, so let's assume this for all others").
>>>
>>
>> I think you're misunderstanding things. There is no requirement on the
>> Servlet API, just that Filter/Interceptor properties are backed by
>> HttpServletRequest in a servlet environment. This makes JAX-RS more
>> seemless integratable.
>>
>> Maybe a changing of the wording is:
>>
>> Properties should be backed by any underyling mechanism to associate
>> properties with the http request. So, a JAX-RS container written on top
>> of the Servlet API should have properties backed by HttpServletRequest
>> attributes. This allows JAX-Rs filters and interceptors to seemlessly
>> pass information between JAX-RS and their underlying http
>> implementations.
>>
>> That clear things up?
>>
> That is reasonable as far as the implementation is concerned but it is
> an implementation detail because the purpose of ContainerRequestContext
> is not to expose or let users modify HttpServletRequest attributes which
> may contain values not even set by JAX-RS related handlers.
>
I'm saying that *IS* the purpose. Allows jax-rs to seemlessly get/set
request properties from its environment without having a hard dependency
on that environment.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com