Question about testing methods which use injected Jersey resources

[nwhite]

I am brand new to Arquillian and I am trying to see if I can use it to test a method which is in JAX-RS/Jersey Resource class which has an injected Context method parameter. For example the method looks like this:

public String listUsers(@Context HttpServletRequest req) {

...

}

Normally Jersey is responsible for injecting the servlet request when this method is called. How is this handled by Arquillian? Do I have to mock that request myself or is there some magical way for Arquillian (using embedded GF) to provide it?

Thanks,

-Noah

[aslak]

I would set @Deployment.testable=false (run as client, not in container) and invoke the endpoint via e.g. htmlunit

[nwhite]

Aslak -

That's interesting - thanks for pointing out that Deployment option. Like I said I'm about 4 hours into using Arquillian :-)

This ReST endpoint is also a CDI RequestScoped bean which has an EJB (that uses JPA) injected into it. So to do full integration test with mocked up data in a test DB I think I'd need to go with the container option wouldn't I? I happen to be using Embedded Glassfish 3.1.

What I ended up doing, and gettting working (after fighting for a while with getting a proper arquillian.xml; see below), before seeing your reply, was to shrinkwrap a war which includes my web.xml which bootstraps Jersey. My test method then uses the Jersey client API to send the request.  This solution kind of gives me a Jersey Test Framework (JTF) like environment but its super charged with all the Arquillian functionality that goes beyond what you can do with JTF. 

Regarding my problems with arquillian.xml. I followed several examples of an arquillian.xml for embedded gf. It appears some of the first ones I came across were out-dated with respect to Alpha5 and GF 3.1 embedded. No worries. What gave me the most trouble was that for a long time I though my arquillian.xml wasn't even being picked up because I was seeing both:

"INFO: Could not read active container configuration: null"

was seeing that it was still trying to use port 8080 vs. the one I had set in arquillian.xml and I was getting exceptions from :

com.sun.hk2.component.ExistingSingletonInhabitant

After wiring up the glassfish-embedded-all sources and stepping through things I realized it was in fact finding/reading the arquillian.xml file but it was puking on my domain.xml file.  Many examples I came across suggested lifting a domain.xml from your GF 3.1 install and stripping everything out of it except for the JDBC Connection Pool and JDBC resources that you want to set up for your Arquillian test environment.

I tried that approach but I it seems it was too extreme. I ended up leaving everything in but removing the JDBC connection pools and JNDI resources I did not need and adding what I did need. That worked. When I have some free time I am going to experiment with pruning out more to see what I can get it down to.

It would be nice if there was a way for Arquillian to report a more relevant message when things go south with the domain.xml. It would have saved me some time and Advil. :-)

It would also be nice if there was a non-maven distribution for Arquillian and said dependcies as well for those of us who want to use Arquillian with non-Maven projects. That would really be a time saver for those projects.I ended up pulling down a project that used Maven/Arquillian - boot strapped my local maven repo with it, and ran a 'find -exec' to manually move the jars into the target project. That was a pain.

Overall though things look great. Its come a long way since I first saw a presentation on it at NEJUG a few years back.

-Noah