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

Romain Manni-Bucau rmannibucau at gmail.com
Thu Sep 8 07:53:32 EDT 2016


AFAIK the server propagates by designt he request/response pair so even if
there is a way to know which one it is at each moment you still have the
issue you don't know what @Inject Request; means. @Inject
@Web(FilterX.class) Request; is possible but not sure the real meaning and
IMO it breaks the loose coupling of CDI so not sure it does worth to
spec-ed it.


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:31 GMT+02:00 arjan tijms <arjan.tijms at gmail.com>:

> Hi,
>
> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <rmannibucau at gmail.com>
> wrote:
>
>> 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).
>>
>
> What I was thinking, but maybe I'm wrong, is that the application never
> "just" wraps the request and uses it for itself. It always passes it to the
> container, which then passes it on to the next Filter, Servlet, or
> whatever. So at that point the container code has the opportunity to store
> the request as being the "current" one.
>
> E.g. if you do:
>
> RequestDispatcher dispatcher = servletContext().getRequestDispatcher(...);
> dispatcher.forward(wrap(request), response);
>
> Then the RequestDispatcher, which is a container class, receives the
> wrapped request and can make it available.
>
> The other way around, eventually every AuthModule, Filter or Servlet has
> to be called by the container at some point. E.g. the "protected void
> service(HttpServletRequest req, HttpServletResponse resp)" is called by the
> container.
>
> So just before the container invokes the HttpServlet#service method, the
> container can store the request, and CDI (via an SPI) can pick it up from
> there.
>
> That way in every context you can always have the *current* request (the
> request that's passed in to the last Servlet or Filter call on the stack).
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>> 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/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.
>>>>>
>>>>>
>>>> --
>>>> 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/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.
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160908/259e42d8/attachment-0001.html 


More information about the cdi-dev mailing list