Hi,
Sorry, forget the AuthModule for now ;) I just put it there because it's
often forgotten that it also gets to see the request and can wrap it, but
for a change (I know, it's rare with me ;)) the issue here is primarily
unrelated to auth.
Kind regards,
Arjan Tijms
On Thu, Sep 8, 2016 at 2:14 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com>
wrote:
Well supposes @Current means something for the component getting the
injection, I can see where you go starting from AuthModule but more your
browse the chain less it makes sense IMO -> maybe something to work on auth
side more than CDI?
That said CDI has a notion for conversions which is to define a provided
filter. Maybe that's the easiest here: a user could define one or multiple
filters ("CDI Filter" or whatever name) which would set CDI position in the
filter chain, defining it N times would update "current" request and the
produces one so we keep current default and enable the user to control it
himself finely when needed.
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 14:10 GMT+02:00 arjan tijms <arjan.tijms(a)gmail.com>:
> Hi,
>
> I see what you mean.
>
> There's perhaps 2 solutions.
>
> 1. Specify @Inject HttpServletRequest to inject the current one (the top
> one from the stack)
> 2. Let @Inject HttpServletRequest as it's now (you get an arbitrary one,
> which is hopefully at least always the same for a given server), and
> introduce a qualifier @Current orso.
>
> I don't think you'd ever need @Inject @Web(FilterX.class) Request, which
> would mean searching back through the stack. If users would want that, they
> have to make their own producer.
>
> What we could do now is:
>
> AuthModule
> |
> |
> Filter1 (calls) ---> BeanX.foo() #1
> |
> |
> Filter2
> |
> |
> Servlet1 (calls) ---> BeanX.foo() #2
> |
> |
> (forward) ---> Servlet2 (calls) ---> BeanX.foo() #3
>
>
>
> If BeanX is injected with @Inject HttpServletRequest or
> @Inject @Current HttpServletRequest, then:
>
>
> In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to
> Filter1
>
> In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to
> Servlet1
>
> In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to
> Servlet2
>
>
>
> Since the request processing is strictly sequential here, a given thread
> always has the concept of the request that was passed it to the
> module/filter/servlet that's highest up the call stack. That one would IMHO
> be the most logical one that you want to work with.
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <rmannibucau(a)gmail.com
> > wrote:
>
>> 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(a)gmail.com>:
>>
>>> Hi,
>>>
>>> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <
>>> rmannibucau(a)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().getRequestDis
>>> patcher(...);
>>> 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(a)gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
<mkouba(a)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(a)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(a)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.
>>>>>
>>>>
>>>>
>>>
>>
>