<div dir="ltr"><div>Hi,</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 8, 2016 at 2: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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">I think this is missing the key insight that CDI extensions are portable<br>
and that it's "just" providing a 1 class extension that adds 3 orso<br>
build-in beans.<br>
</span></blockquote>
<br>
Stuart has a good point about backward compatibility. Servlet impl would have to detect CDI version and skip registration if not 2.0+. I think SERVLET_SPEC-116 should be reopened and the discussion restarted.<br></blockquote><div><br></div><div>Indeed, that is a good point, but that's basically part of the challenge of moving those build-in beans. If I'm not mistaken Antoine once mentioned in one of the other related issues something along the line that CDI 2.0 could provide something for that. So the "is 2.0+" check could be made easier or more straightforward.</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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
<br>
But it's more complicated then it sounds. For example,<br>
HttpServletRequest attibutes might be used as backing storage of the<br>
request context. So that it cannot simply change...<br>
<br>
Anyway, I think this problem deserves some attention from both the<br>
CDI and the Servlet EG.<br>
<br>
Martin<br>
<br>
Dne 8.9.2016 v 13:31 arjan tijms napsal(a):<br>
<br>
Hi,<br>
<br>
On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau<br>
<<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><br></span>
<mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> <mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>><wbr>>><div><div class="h5"><br>
wrote:<br>
<br>
Hit that issue as well several times.<br>
<br>
It is more vicious than it looks like IMO cause CDI will<br>
*never* get<br>
*the* right request for everybody, it is as simple as that.<br>
Any part<br>
of the app can rely on the wrapper level N (of course N being<br>
different for each mentionned parts of the app).<br>
<br>
<br>
What I was thinking, but maybe I'm wrong, is that the<br>
application never<br>
"just" wraps the request and uses it for itself. It always<br>
passes it to<br>
the container, which then passes it on to the next Filter,<br>
Servlet, or<br>
whatever. So at that point the container code has the opportunity to<br>
store the request as being the "current" one.<br>
<br>
E.g. if you do:<br>
<br>
RequestDispatcher dispatcher =<br>
servletContext().getRequestDis<wbr>patcher(...);<br>
dispatcher.forward(wrap(reques<wbr>t), response);<br>
<br>
Then the RequestDispatcher, which is a container class, receives the<br>
wrapped request and can make it available.<br>
<br>
The other way around, eventually every AuthModule, Filter or<br>
Servlet has<br>
to be called by the container at some point. E.g. the "protected<br>
void<br>
service(HttpServletRequest req, HttpServletResponse resp)" is<br>
called by<br>
the container.<br>
<br>
So just before the container invokes the HttpServlet#service<br>
method, the<br>
container can store the request, and CDI (via an SPI) can pick it up<br>
from there.<br>
<br>
That way in every context you can always have the *current*<br>
request (the<br>
request that's passed in to the last Servlet or Filter call on<br>
the stack).<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Best CDI can do is to provide the request it has (already<br>
the case<br>
and cost pretty much nothing) and enable the user to<br>
produces very<br>
easily its own request from its filter (or equivalent) for<br>
its usage<br>
IMO - which is IMO already doable but maybe there is another<br>
shortcut we can introduce I didnt think about. If you look<br>
one step<br>
further any web framework built on top of CDI does it and<br>
therefore<br>
runs in a well known context.<br>
<br>
<br>
Romain Manni-Bucau<br>
@rmannibucau <<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibuc<wbr>au</a><br>
<<a href="https://twitter.com/rmannibucau" rel="noreferrer" target="_blank">https://twitter.com/rmannibuc<wbr>au</a>>> | Blog<br>
<<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.rhcl<wbr>oud.com</a><br>
<<a href="https://blog-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://blog-rmannibucau.rhcl<wbr>oud.com</a>>> | Old Wordpress Blog<br>
<<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.<wbr>com</a><br>
<<a href="http://rmannibucau.wordpress.com" rel="noreferrer" target="_blank">http://rmannibucau.wordpress.<wbr>com</a>>> | Github<br>
<<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibuca<wbr>u</a><br>
<<a href="https://github.com/rmannibucau" rel="noreferrer" target="_blank">https://github.com/rmannibuca<wbr>u</a>>> | LinkedIn<br>
<<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/r<wbr>mannibucau</a><br>
<<a href="https://www.linkedin.com/in/rmannibucau" rel="noreferrer" target="_blank">https://www.linkedin.com/in/r<wbr>mannibucau</a>>> | Tomitriber<br>
<<a href="http://www.tomitribe.com" rel="noreferrer" target="_blank">http://www.tomitribe.com</a>> | JavaEE Factory<br>
<<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-rmannib<wbr>ucau.rhcloud.com</a><br>
<<a href="https://javaeefactory-rmannibucau.rhcloud.com" rel="noreferrer" target="_blank">https://javaeefactory-rmannib<wbr>ucau.rhcloud.com</a>>><br>
<br>
2016-09-08 13:03 GMT+02:00 arjan tijms<br>
<<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><br></div></div>
<mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a> <mailto:<a href="mailto:arjan.tijms@gmail.com" target="_blank">arjan.tijms@gmail.com</a>><wbr>>>:<span class=""><br>
<br>
Hi,<br>
<br>
On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba<br>
<<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>><br></span>
<mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>>><div><div class="h5"><br>
wrote:<br>
<br>
that's a good question. In Weld, the request object is<br>
captured during request context activation, i.e. during<br>
ServletRequestListener.request<wbr>Initialized()<br>
notification and<br>
before any filter or servlet is invoked. So wrappers are<br>
ignored and the original/first request is used.<br>
<br>
<br>
Indeed, although do note that some servers (Liberty and<br>
WebLogic<br>
I think) send the<br>
ServletRequestListener.request<wbr>Initialized()<br>
notification rather late, and do that after the application<br>
already has seen the request and has had a chance to<br>
wrap it.<br>
This by itself is a separate problem. So on these<br>
servers, Weld<br>
would receive an early request but not necessarily the<br>
earliest.<br>
<br>
<br>
But TBH I don't think we can fix this easily as I'm not<br>
aware of any portable way to listen for "wrapping<br>
actions".<br>
<br>
<br>
This would have to happen with Server specific code I guess,<br>
just as Weld now requires an SPI to obtain the current<br>
principal<br>
for injection.<br>
<br>
You could say that the Servlet container could store the<br>
request<br>
"somewhere" on a stack structure, just before it invokes the<br>
ServerAuthModule, Filter, Servlet and anything else I<br>
may have<br>
forgotten, and then when control flows back to each Servlet,<br>
Filter, etc unwind that stack.<br>
<br>
At the very least the spec for now should perhaps<br>
clarify this?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
<br>
Martin<br>
<br>
Dne 8.9.2016 v 11:02 arjan tijms napsal(a):<br>
<br>
Hi,<br>
<br>
The CDI spec defines a built-in bean for the type<br>
HttpServletRequest. In<br>
3.8 it says:<br>
<br>
"A servlet container must provide the following<br>
built-in<br>
beans, all of<br>
which have qualifier @Default:<br>
<br>
a bean with bean type<br>
javax.servlet.http.HttpServlet<wbr>Request, allowing<br>
injection of a reference to the HttpServletRequest"<br>
<br>
An HttpServletRequest however can be wrapped<br>
multiple<br>
times and by<br>
multiple artefacts. I.e. by a ServerAuthModule,<br>
Filter and a<br>
RequestDispatcher.<br>
<br>
The question now is; which version of the<br>
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<br>
it's now<br>
often "one of<br>
the first ones", e.g. the one that happened to be<br>
current when e.g. a<br>
ServletRequestListener that initialises a<br>
specific CDI<br>
implementation is<br>
called.<br>
<br>
I think this is a little confusing, as working<br>
with an<br>
injected request<br>
can now totally ignore the request wrapping that has<br>
been done and break<br>
an application badly.<br>
<br>
Thoughts?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<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></div></div>
<mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a>> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a><span class=""><br>
<mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</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>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a>><br>
<br>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a><br>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a>>><br>
<br>
Note that for all code provided on this list, the<br>
provider licenses the code under the Apache License,<br>
Version 2<br>
(<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><br>
<<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>><br>
<<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><br>
<<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<br>
all other ideas provided on this list, the provider<br>
waives all patent and other intellectual<br>
property rights<br>
inherent in such information.<br>
<br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a>><br></span>
<mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.or<wbr>g</a>>><span class=""><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>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a>><br>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a><br>
<<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailm<wbr>an/listinfo/cdi-dev</a>>><br>
<br>
Note that for all code provided on this list, the provider<br>
licenses the code under the Apache License, Version 2<br>
(<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><br>
<<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>><br>
<<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><br>
<<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<br>
other ideas provided on this list, the provider waives all<br>
patent and other intellectual property rights inherent<br>
in such<br>
information.<br>
<br>
<br>
<br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</div></div></blockquote></div><br></div></div>