On 07/09/12 15:40, Bill Burke wrote:
>
>
> 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.
Sounds like we are in agreement ? If so, why mention Servlet request in
the documentation and give users the message that they may also use the
API to work work with HttpServletRequest. By the way, in my previous
comment I also indicated is that actually all HTTP attributes will be
leaked as a result and that is wrong IMHO, given that the goal is to
pass the properties between the filters, not provide an interface to
HttpServletRequest
Cheers, Sergey