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.
Example, in CXF, at the HTTP transport implementation level, we pass on
some properties as HTTP attributes, why the user needs to see those in
getPropertyNames() ?
Cheers, Sergey
> FYI, similarly, I'm pushing for Configurable.properties to be backed by
> ServletContext init/context params so you can easily pass config from
> web.xml into your components.
>
>
>