<div dir="ltr">Hi,<div><br></div><div>I see what you mean.</div><div><br></div><div>There's perhaps 2 solutions.</div><div><br></div><div>1. Specify @Inject HttpServletRequest to inject the current one (the top one from the stack)</div><div>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.</div><div><br></div><div>I don't think you'd ever need <span style="font-size:12.8px">@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.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">What we could do now is:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">AuthModule</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">Filter1 (calls) ---> BeanX.foo() #1</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">Filter2 </span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">Servlet1 (calls) ---> BeanX.foo() #2</span><br></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">|</span></div><div><span style="font-size:12.8px">(forward) ---> Servlet2 (calls) ---> BeanX.foo() #3</span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><br></div><div><span style="font-size:12.8px">If BeanX is injected with </span>@Inject HttpServletRequest or @Inject @Current HttpServletRequest, then:</div><div><br></div><div><br></div><div>In #1, BeanX.foo() sees the HttpServletRequest as it was passed in to Filter1</div><div><br></div><div>In #2, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet1<br></div><div><br></div><div>In #3, BeanX.foo() sees the HttpServletRequest as it was passed in to Servlet2<br></div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 1:53 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div><div class="gmail_extra"><span class=""><br clear="all"><div><div data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="https://blog-rmannibucau.rhcloud.com" target="_blank">Blog</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Old Wordpress Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a> | <a href="https://javaeefactory-rmannibucau.rhcloud.com" target="_blank">JavaEE Factory</a></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br></span><div><div class="h5"><div class="gmail_quote">2016-09-08 13:31 GMT+02:00 arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau <span dir="ltr"><<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hit that issue as well several times.<div><br></div><div>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).</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>E.g. if you do:<br><br><div>RequestDispatcher dispatcher = servletContext().getRequestDis<wbr>patcher(...);</div><div>dispatcher.forward(wrap(reques<wbr>t), response);<br><br>Then the RequestDispatcher, which is a container class, receives the wrapped request and can make it available.</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> 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.<span><font color="#888888"><br></font></span><div class="gmail_extra"><span><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="https://blog-rmannibucau.rhcloud.com" target="_blank">Blog</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Old Wordpress Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a> | <a href="https://javaeefactory-rmannibucau.rhcloud.com" target="_blank">JavaEE Factory</a></div></div></div></div></div></div></div></div></div></div></div></div></div></div></font></span><div><div>
<br><div class="gmail_quote">2016-09-08 13:03 GMT+02:00 arjan tijms <span dir="ltr"><<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">that's a good question. In Weld, the request object is captured during request context activation, i.e. during ServletRequestListener.request<wbr>Initialized() notification and before any filter or servlet is invoked. So wrappers are ignored and the original/first request is used.<br></blockquote><div><br></div></span><div>Indeed, although do note that some servers (Liberty and WebLogic I think) send the ServletRequestListener.req<wbr>uestInitialized() 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.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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".<br></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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.</div><div><br></div><div>At the very least the spec for now should perhaps clarify this?</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
Martin<br>
<br>
Dne 8.9.2016 v 11:02 arjan tijms napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>
Hi,<br>
<br>
The CDI spec defines a built-in bean for the type HttpServletRequest. In<br>
3.8 it says:<br>
<br>
"A servlet container must provide the following built-in beans, all of<br>
which have qualifier @Default:<br>
<br>
a bean with bean type javax.servlet.http.HttpServlet<wbr>Request, allowing<br>
injection of a reference to the HttpServletRequest"<br>
<br>
An HttpServletRequest however can be wrapped multiple times and by<br>
multiple artefacts. I.e. by a ServerAuthModule, Filter and a<br>
RequestDispatcher.<br>
<br>
The question now is; which version of the HttpServletRequest is supposed<br>
to be injected?<br>
<br>
* The first one in the chain?<br>
* The last one in the chain?<br>
* The current one at a given point in the chain?<br>
<br>
A little bit of experimenting seems to indicate it's now often "one of<br>
the first ones", e.g. the one that happened to be current when e.g. a<br>
ServletRequestListener that initialises a specific CDI implementation is<br>
called.<br>
<br>
I think this is a little confusing, as working with an injected request<br>
can now totally ignore the request wrapping that has been done and break<br>
an application badly.<br>
<br>
Thoughts?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br></div></div>
______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br><span><font color="#888888">
</font></span></blockquote><span><font color="#888888">
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</font></span></blockquote></div></div></div><br></div></div>
<br>______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailma<wbr>n/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/license<wbr>s/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br></div></div></div></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>