[cdi-dev] Which version of HttpServletRequest is injected?

Thu Sep 8 07:09:42 EDT 2016

Hit that issue as well several times.

It is more vicious than it looks like IMO cause CDI will *never* get *the*
right request for everybody, it is as simple as that. Any part of the app
can rely on the wrapper level N (of course N being different for each
mentionned parts of the app). Best CDI can do is to provide the request it
has (already the case and cost pretty much nothing) and enable the user to
produces very easily its own request from its filter (or equivalent) for
its usage IMO - which is IMO already doable but maybe there is another
shortcut we can introduce I didnt think about. If you look one step further
any web framework built on top of CDI does it and therefore runs in a well
known context.

Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>

2016-09-08 13:03 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <mkouba at redhat.com> wrote:
>
>> that's a good question. In Weld, the request object is captured during
>> request context activation, i.e. during ServletRequestListener.requestInitialized()
>> notification and before any filter or servlet is invoked. So wrappers are
>> ignored and the original/first request is used.
>>
>
> Indeed, although do note that some servers (Liberty and WebLogic I think)
> send the ServletRequestListener.requestInitialized() notification rather
> late, and do that after the application already has seen the request and
> has had a chance to wrap it. This by itself is a separate problem. So on
> these servers, Weld would receive an early request but not necessarily the
> earliest.
>
>
>> But TBH I don't think we can fix this easily as I'm not aware of any
>> portable way to listen for "wrapping actions".
>>
>
> This would have to happen with Server specific code I guess, just as Weld
> now requires an SPI to obtain the current principal for injection.
>
> You could say that the Servlet container could store the request
> "somewhere" on a stack structure, just before it invokes the
> ServerAuthModule, Filter, Servlet and anything else I may have forgotten,
> and then when control flows back to each Servlet, Filter, etc unwind that
> stack.
>
> At the very least the spec for now should perhaps clarify this?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>>
>> Martin
>>
>> Dne 8.9.2016 v 11:02 arjan tijms napsal(a):
>>
>>> Hi,
>>>
>>> The CDI spec defines a built-in bean for the type HttpServletRequest. In
>>> 3.8 it says:
>>>
>>> "A servlet container must provide the following built-in beans, all of
>>> which have qualifier @Default:
>>>
>>> a bean with bean type javax.servlet.http.HttpServletRequest, allowing
>>> injection of a reference to the HttpServletRequest"
>>>
>>> An HttpServletRequest however can be wrapped multiple times and by
>>> multiple artefacts. I.e. by a ServerAuthModule, Filter and a
>>> RequestDispatcher.
>>>
>>> The question now is; which version of the HttpServletRequest is supposed
>>> to be injected?
>>>
>>> * The first one in the chain?
>>> * The last one in the chain?
>>> * The current one at a given point in the chain?
>>>
>>> A little bit of experimenting seems to indicate it's now often "one of
>>> the first ones", e.g. the one that happened to be current when e.g. a
>>> ServletRequestListener that initialises a specific CDI implementation is
>>> called.
>>>
>>> I think this is a little confusing, as working with an injected request
>>> can now totally ignore the request wrapping that has been done and break
>>> an application badly.
>>>
>>> Thoughts?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the
>>> code under the Apache License, Version 2 (http://www.apache.org/license
>>> s/LICENSE-2.0.html). For all other ideas provided on this list, the
>>> provider waives all patent and other intellectual property rights inherent
>>> in such information.
>>>
>>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>>
>
>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
> code under the Apache License, Version 2 (http://www.apache.org/
> licenses/LICENSE-2.0.html). For all other ideas provided on this list,
> the provider waives all patent and other intellectual property rights
> inherent in such information.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/ab4e63c2/attachment-0001.html 