I don't understand why I cannot reproduce this success.

My tests were done using the runtime of a tomee snapshot containing your
change, plus the arquillian jars.
Suspecting I had some classpath issues, I tried the following steps:
- checkout the current tomee trunk
- build the arquillian jaxrs tests, and run them with maven: all green
- change one of the tests, to include a request scoped cdi bean in the
service, those bean has HttpHeaders injected
- re-run the tests: the modified one fails, the HttpHeaders are not injected

The latest tomee 1.6.0-SNAPSHOT jars are used by maven, I don't understand
what is going on.

Regards,
antoine

On Thu, Apr 25, 2013 at 5:11 PM, Romain Manni-Bucau
<[email protected]>wrote:

> works fine ;)
>
> joke apart here what i did:
>
> first i used maven to get dependencies (was too long to get them one by
> one):
>
> <dependency>
>       <groupId>org.apache.openejb</groupId>
>       <artifactId>javaee-api</artifactId>
>       <version>6.0-5</version>
>       <scope>provided</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <version>1.0.3.Final</version>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.openejb</groupId>
>       <artifactId>arquillian-tomee-remote</artifactId>
>       <version>1.6.0-SNAPSHOT</version>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.openejb</groupId>
>       <artifactId>ziplock</artifactId>
>       <version>1.6.0-SNAPSHOT</version>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <version>4.11</version>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.apache.cxf</groupId>
>       <artifactId>cxf-rt-frontend-jaxrs</artifactId>
>       <version>2.6.7</version>
>       <scope>test</scope>
>     </dependency>
>
> then updated your arquillian.xml to configure the container this way:
>
>   <container qualifier="tomee" default="true">
>     <configuration>
>       <property name="httpPort">7024</property>
>       <property name="stopPort">7025</property>
>       <property name="classifier">jaxrs</property>
>       <property name="dir">target/apache-tomee</property>
>       <property
> name="appWorkingDir">target/arquillian-test-working-dir</property>
>     </configuration>
>   </container>
>
> finally to use @ArquillianResource URL url; i deactivated server enrichment
> with @Deployment(testable = false)
>
> all is green now
>
> PS: replacing arquillian-tomee-remote by arquillian-tomee-embedded works
> fine onece the following dep is added:
>
> <dependency>
>       <groupId>org.apache.openejb</groupId>
>       <artifactId>tomee-jaxrs</artifactId>
>       <version>1.6.0-SNAPSHOT</version>
>     </dependency>
>
> *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/25 Antoine Reilles <[email protected]>
>
> > Hi,
> >
> > Indeed, this works fine with the latest snapshots of tomee.
> > However, I have difficulties to make this work using arquillian.
> > Attached is a sample project where I used a recent tomee 1.6.0 snapshot,
> > and arquillian 1.0.3.
> > The sample works fin when bundled in a war for tomee, but fails when ran
> > using arquillian.
> > Any clue of what could go wrong ?
> >
> > Cheers,
> > antoine
> >
> > On Mon, Apr 8, 2013 at 9:48 AM, Romain Manni-Bucau <
> [email protected]>wrote:
> >
> >> https://issues.apache.org/jira/browse/TOMEE-888
> >>
> >> done ;)
> >>
> >> 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
> >> >>>> >
> >> >>>>
> >> >>>
> >> >>>
> >> >
> >>
> >
> >
>

Reply via email to