Problem here is that maybe only the dev system is TomEE.  Maybe production
is another app server.  If you do something like this, it may become
difficult to debug.  At a bare minimum it should be documented that TomEE+
has this non-spec mandated injection target created for CDI beans that
users may use at their own will but is not considered portable.

If the docs are in a repo somewhere I can send a pull request for the
change.


On Mon, Apr 8, 2013 at 10:02 AM, Romain Manni-Bucau
<rmannibu...@gmail.com>wrote:

> @john: yep, here i think offering the feature costs nothing for us and
> helps the user to don't care about the spec. Implementing 100% the specs
> with their spirits sometimes make the container not usable ;). And once
> again the spec never said it was not available for CDI beans, the spec
> states it is available for resource beans and as others @resource are
> available for cdi beans it seems consistent to offer it for me
>
> *Romain Manni-Bucau*
> *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> *Blog: **http://rmannibucau.wordpress.com/*<
> http://rmannibucau.wordpress.com/>
> *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> *Github: https://github.com/rmannibucau*
>
>
>
> 2013/4/8 John D. Ament <john.d.am...@gmail.com>
>
> > Not from TomEE examples, but by understanding the JAX-RS spec a little
> bit.
> >
> > I think (IMHO) sometimes as open source programmers we jump quickly on
> the
> > "OMG someone found an issue I can fix" before we think "is this really an
> > issue with the product or a limitation of the spec that the product
> > implements?"  (not anything against Romain mind you)
> >
> >
> > On Mon, Apr 8, 2013 at 9:53 AM, Howard W. Smith, Jr. <
> > smithh032...@gmail.com
> > > wrote:
> >
> > > Ditto ( +1 ) and +1 this topic/thread and the responses. Definitely,
> good
> > > to know as I am hoping to use (REST) web services via TomEE, ASAP.
> > >
> > > Could this question/issue have been avoided after reading/reviewing
> TomEE
> > > documentation/examples?
> > >
> > >
> > > On Mon, Apr 8, 2013 at 9:30 AM, Romain Manni-Bucau <
> > rmannibu...@gmail.com
> > > >wrote:
> > >
> > > > yep +1
> > > >
> > > > *Romain Manni-Bucau*
> > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > http://rmannibucau.wordpress.com/>
> > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > *Github: https://github.com/rmannibucau*
> > > >
> > > >
> > > >
> > > > 2013/4/8 John D. Ament <john.d.am...@gmail.com>
> > > >
> > > > > Right, but it's still a server specific solution.  Not a portable
> > > > solution.
> > > > >  The use of @Context in a CDI is especially bad since only @Inject
> > and
> > > > @EJB
> > > > > type injection is meant to work.
> > > > >
> > > > >
> > > > > On Mon, Apr 8, 2013 at 9:01 AM, Romain Manni-Bucau <
> > > > rmannibu...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > but now it works (and that's not forbidden by the spec AFAIK). DS
> > > > doesn't
> > > > > > have it ATM. The best alternative today is a web filter + a
> > > threadlocal
> > > > > > IMO.
> > > > > >
> > > > > > what is common is to get it from the rest endpoints then
> propagate
> > it
> > > > to
> > > > > > cdi beans
> > > > > >
> > > > > > all depends on your model
> > > > > >
> > > > > > *Romain Manni-Bucau*
> > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > http://rmannibucau.wordpress.com/>
> > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > *Github: https://github.com/rmannibucau*
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2013/4/8 John D. Ament <john.d.am...@gmail.com>
> > > > > >
> > > > > > > Sorry , just noticed this was on the list twice.
> > > > > > >
> > > > > > > I believe this change actually violates the JAX-RS 1.1 spec,
> see
> > > > here:
> > > > > > >
> > > http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-520005
> > > > > > >
> > > > > > > JAX-RS provides facilities for obtaining and processing
> > information
> > > > > about
> > > > > > > the application deployment context and the context of
> individual
> > > > > > requests.
> > > > > > > Such information is available to Application subclasses (see
> > > section
> > > > > > > 2.1<
> > > > > >
> > > http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-110002.1
> > > > > > > >),
> > > > > > > root resource classes (see chapter
> > > > > > > 3<
> > > > http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-180003
> > > > > >),
> > > > > > > and providers (see chapter
> > > > > > > 4<
> > > > http://jsr311.java.net/nonav/releases/1.1/spec/spec3.html#x3-390004
> > > > > >).
> > > > > > > This chapter describes these facilities.
> > > > > > >
> > > > > > > CDI beans are none of those.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Apr 8, 2013 at 3:48 AM, Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > https://issues.apache.org/jira/browse/TOMEE-888
> > > > > > > >
> > > > > > > > done ;)
> > > > > > > >
> > > > > > > > *Romain Manni-Bucau*
> > > > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > > > http://rmannibucau.wordpress.com/>
> > > > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > > > *Github: https://github.com/rmannibucau*
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2013/4/8 Romain Manni-Bucau <rmannibu...@gmail.com>
> > > > > > > >
> > > > > > > > > ok,
> > > > > > > > >
> > > > > > > > > the issue is the @Context resources are basically only
> > > available
> > > > > for
> > > > > > > rest
> > > > > > > > > endpoints ATM
> > > > > > > > >
> > > > > > > > > i'll dig to see if we can make it available to cdi beans
> > > without
> > > > > > > getting
> > > > > > > > a
> > > > > > > > > big extra cost
> > > > > > > > >
> > > > > > > > > *Romain Manni-Bucau*
> > > > > > > > > *Twitter: @rmannibucau <https://twitter.com/rmannibucau>*
> > > > > > > > > *Blog: **http://rmannibucau.wordpress.com/*<
> > > > > > > > http://rmannibucau.wordpress.com/>
> > > > > > > > > *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
> > > > > > > > > *Github: https://github.com/rmannibucau*
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2013/4/8 Romain Manni-Bucau <rmannibu...@gmail.com>
> > > > > > > > >
> > > > > > > > >> Think i know, can you try ServletRequest instead of
> > > > > > httpservletrequest
> > > > > > > > >> please (ill get a computer in 1h to go further)
> > > > > > > > >> Le 8 avr. 2013 08:13, "Antoine Reilles" <
> > > > areilles+to...@gmail.com
> > > > > >
> > > > > > a
> > > > > > > > >> écrit :
> > > > > > > > >>
> > > > > > > > >>  Sure, here is the war I used, with its sources.
> > > > > > > > >>> I tried to get the sample minimalist, so it almost only
> > > > performs
> > > > > > > > >>> System.out traces.
> > > > > > > > >>>
> > > > > > > > >>> On Mon, Apr 8, 2013 at 7:58 AM, Romain Manni-Bucau <
> > > > > > > > >>> rmannibu...@gmail.com> wrote:
> > > > > > > > >>>
> > > > > > > > >>>> Hi
> > > > > > > > >>>>
> > > > > > > > >>>> You seem to have a sample project, can you share it or
> the
> > > war
> > > > > > > > >>>> associated
> > > > > > > > >>>> please?
> > > > > > > > >>>> Le 8 avr. 2013 07:55, "Antoine Reilles" <
> > > > > areilles+to...@gmail.com
> > > > > > >
> > > > > > > a
> > > > > > > > >>>> écrit :
> > > > > > > > >>>>
> > > > > > > > >>>> > Hi,
> > > > > > > > >>>> >
> > > > > > > > >>>> > I'm running into issues when defining a RequestScoped
> > CDI
> > > > bean
> > > > > > to
> > > > > > > be
> > > > > > > > >>>> > injected in a jax-rs service, and initialized with
> > > > information
> > > > > > > from
> > > > > > > > >>>> the
> > > > > > > > >>>> > http request.
> > > > > > > > >>>> > My first problem is that the @Context
> HttpServletRequest
> > > > that
> > > > > > gets
> > > > > > > > >>>> injected
> > > > > > > > >>>> > in the CDI bean is invalid (the threadlocal proxy
> points
> > > to
> > > > > > null,
> > > > > > > > thus
> > > > > > > > >>>> > raising NPE when a method is called on the object)
> > > whenever
> > > > > the
> > > > > > > same
> > > > > > > > >>>> > @Context HttpServletRequest is not injected in the
> > jax-rs
> > > > > > context.
> > > > > > > > If
> > > > > > > > >>>> the
> > > > > > > > >>>> > servletrequest in injected in the jax-rs endpoint,
> then
> > it
> > > > is
> > > > > > > > properly
> > > > > > > > >>>> > available from the CDI bean.
> > > > > > > > >>>> > The second issue I have is that injecting the
> > > > > > HttpServletResponse
> > > > > > > in
> > > > > > > > >>>> the
> > > > > > > > >>>> > CDI bean makes it available with the same limitations
> as
> > > the
> > > > > > > > >>>> > HttpServletRequest, but it is no more available
> (again,
> > a
> > > > > thread
> > > > > > > > local
> > > > > > > > >>>> > proxy pointing to null) in the @PreDestroy method of
> the
> > > CDI
> > > > > > bean.
> > > > > > > > >>>> >
> > > > > > > > >>>> > Here are samples of what I used to test, I can
> provide a
> > > > > > complete
> > > > > > > > >>>> sample if
> > > > > > > > >>>> > it is useful.
> > > > > > > > >>>> >
> > > > > > > > >>>> > The service is simply:
> > > > > > > > >>>> > @Path("service")
> > > > > > > > >>>> > @Produces(MediaType.TEXT_PLAIN)
> > > > > > > > >>>> > public class Service {
> > > > > > > > >>>> >   @Context HttpServletRequest request;
> > > > > > > > >>>> >   @Context HttpServletResponse response;
> > > > > > > > >>>> >   @Inject Ctx ctx;
> > > > > > > > >>>> >
> > > > > > > > >>>> >   @GET
> > > > > > > > >>>> >   public String foo() {
> > > > > > > > >>>> >     return "foo: "+ctx;
> > > > > > > > >>>> >   }
> > > > > > > > >>>> > }
> > > > > > > > >>>> >
> > > > > > > > >>>> > with the two @Context annotated fields triggering
> > > different
> > > > > > > behavior
> > > > > > > > >>>> in the
> > > > > > > > >>>> > CDI bean when commented out.
> > > > > > > > >>>> > The CDI bean itself is:
> > > > > > > > >>>> > @RequestScoped
> > > > > > > > >>>> > public class Ctx {
> > > > > > > > >>>> >
> > > > > > > > >>>> >   @Context HttpServletRequest request;
> > > > > > > > >>>> >   @Context HttpServletResponse response;
> > > > > > > > >>>> >   private String requesturi;
> > > > > > > > >>>> >   Ctx() {
> > > > > > > > >>>> >     requesturi = null;
> > > > > > > > >>>> >   }
> > > > > > > > >>>> >
> > > > > > > > >>>> >   @PostConstruct
> > > > > > > > >>>> >   public void postConstruct() {
> > > > > > > > >>>> >     ServletRequest localreq =
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > >
> > > > >
> > ((org.apache.openejb.rest.ThreadLocalHttpServletRequest)request).get();
> > > > > > > > >>>> >     if (null == localreq) {
> > > > > > > > >>>> >       System.out.println("null request injected");
> > > > > > > > >>>> >     } else {
> > > > > > > > >>>> >       requesturi = request.getRequestURI();
> > > > > > > > >>>> >     }
> > > > > > > > >>>> >     System.out.println("Ctx @PostConstruct:"+this);
> > > > > > > > >>>> >     ServletResponse localResp =
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > >
> > > > > >
> > > >
> > ((org.apache.openejb.rest.ThreadLocalHttpServletResponse)response).get();
> > > > > > > > >>>> >     if (null == localResp) {
> > > > > > > > >>>> >       System.out.println("null response injected");
> > > > > > > > >>>> >     } else {
> > > > > > > > >>>> >       System.out.println("Ctx @PostConstruct Response:
> > > > > > > > >>>> > "+response.getStatus());
> > > > > > > > >>>> >     }
> > > > > > > > >>>> >   }
> > > > > > > > >>>> >
> > > > > > > > >>>> >   @PreDestroy
> > > > > > > > >>>> >   public void preDestroy() {
> > > > > > > > >>>> >     System.out.println("Ctx @PreDestroy:"+this);
> > > > > > > > >>>> >     ServletResponse localResp =
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > >
> > > > > >
> > > >
> > ((org.apache.openejb.rest.ThreadLocalHttpServletResponse)response).get();
> > > > > > > > >>>> >     if (null == localResp) {
> > > > > > > > >>>> >       System.out.println("null response injected at
> > > > > > preDestroy");
> > > > > > > > >>>> >     } else {
> > > > > > > > >>>> >       System.out.println("Ctx @PreDestroy Response:
> > > > > > > > >>>> > "+response.getStatus());
> > > > > > > > >>>> >     }
> > > > > > > > >>>> >   }
> > > > > > > > >>>> > }
> > > > > > > > >>>> >
> > > > > > > > >>>> > I had to resort to casts to
> > ThreadLocalHttpServletRequest
> > > to
> > > > > > test
> > > > > > > > the
> > > > > > > > >>>> > injected proxies, since calling any method on a proxy
> > > > pointing
> > > > > > > null
> > > > > > > > >>>> > triggers an NPE, to display traces.
> > > > > > > > >>>> > When the two @Context annotated fields are present in
> > the
> > > > > > Service
> > > > > > > > >>>> class, I
> > > > > > > > >>>> > do get traces like this:
> > > > > > > > >>>> > Ctx @PostConstruct:Ctx: service
> > > > > > > > >>>> > Ctx @PostConstruct Response: 200
> > > > > > > > >>>> > Ctx @PreDestroy:Ctx: service
> > > > > > > > >>>> > null response injected at preDestroy
> > > > > > > > >>>> >
> > > > > > > > >>>> > and when the two fields are commented out in the
> Service
> > > > > class,
> > > > > > > the
> > > > > > > > >>>> traces
> > > > > > > > >>>> > are:
> > > > > > > > >>>> > null request injected
> > > > > > > > >>>> > Ctx @PostConstruct:Ctx: null
> > > > > > > > >>>> > null response injected
> > > > > > > > >>>> > Ctx @PreDestroy:Ctx: null
> > > > > > > > >>>> > null response injected at preDestroy
> > > > > > > > >>>> >
> > > > > > > > >>>> >
> > > > > > > > >>>> > I tested this behavior with 1.5.1, 1.5.2 and todays
> > 1.6.0
> > > > > > > snapshot,
> > > > > > > > >>>> and got
> > > > > > > > >>>> > the very same behavior.
> > > > > > > > >>>> >
> > > > > > > > >>>> > Any suggestions on how I could make this work ?
> > > > > > > > >>>> >
> > > > > > > > >>>> > Best regards,
> > > > > > > > >>>> > antoine
> > > > > > > > >>>> >
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to