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 <[email protected]>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 <[email protected]> > > > 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 < > [email protected] > > >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 <[email protected]> > > > > > > > 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 <[email protected]> > > > > > > > >> 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" <[email protected]> > 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 < > > > >>> [email protected]> 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" <[email protected] > > > > 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 > > > >>>> > > > > >>>> > > > >>> > > > >>> > > > > > > > > > >
