p.s.
On Thu, Sep 8, 2016 at 2:40 PM, Martin Kouba <mkouba(a)redhat.com> wrote:
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.
Would you like to re-open that discussion on the Servlet list? Would be
good to have someone from the CDI EG explaining the case I think.
Kind regards,
Arjan Tijms
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
> But it's more complicated then it sounds. For example,
> HttpServletRequest attibutes might be used as backing storage of the
> request context. So that it cannot simply change...
>
> Anyway, I think this problem deserves some attention from both the
> CDI and the Servlet EG.
>
> Martin
>
> Dne 8.9.2016 v 13:31 arjan tijms napsal(a):
>
> Hi,
>
> On Thu, Sep 8, 2016 at 1:09 PM, Romain Manni-Bucau
> <rmannibucau(a)gmail.com <mailto:rmannibucau@gmail.com>
> <mailto:rmannibucau@gmail.com
<mailto:rmannibucau@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
> <
https://twitter.com/rmannibucau>> | Blog
> <
https://blog-rmannibucau.rhcloud.com
> <
https://blog-rmannibucau.rhcloud.com>> | Old Wordpress Blog
> <
http://rmannibucau.wordpress.com
> <
http://rmannibucau.wordpress.com>> | Github
> <
https://github.com/rmannibucau
> <
https://github.com/rmannibucau>> | LinkedIn
> <
https://www.linkedin.com/in/rmannibucau
> <
https://www.linkedin.com/in/rmannibucau>> | Tomitriber
> <
http://www.tomitribe.com> | JavaEE Factory
> <
https://javaeefactory-rmannibucau.rhcloud.com
> <
https://javaeefactory-rmannibucau.rhcloud.com>>
>
> 2016-09-08 13:03 GMT+02:00 arjan tijms
> <arjan.tijms(a)gmail.com <mailto:arjan.tijms@gmail.com>
> <mailto:arjan.tijms@gmail.com <mailto:arjan.tijms@gmail.com>
> >>:
>
> Hi,
>
> On Thu, Sep 8, 2016 at 12:40 PM, Martin Kouba
> <mkouba(a)redhat.com <mailto:mkouba@redhat.com>
> <mailto:mkouba@redhat.com
<mailto:mkouba@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
> <mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org
> <mailto:cdi-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
> <
https://lists.jboss.org/mailman/listinfo/cdi-dev>
>
> <
https://lists.jboss.org/mailman/listinfo/cdi-dev
> <
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
> <
http://www.apache.org/licenses/LICENSE-2.0.html>
> <
http://www.apache.org/licenses/LICENSE-2.0.html
> <
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 <mailto:cdi-dev@lists.jboss.org>
> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
> <
https://lists.jboss.org/mailman/listinfo/cdi-dev>
> <
https://lists.jboss.org/mailman/listinfo/cdi-dev
> <
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
> <
http://www.apache.org/licenses/LICENSE-2.0.html>
> <
http://www.apache.org/licenses/LICENSE-2.0.html
> <
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