Arquillian with Glassfish 4 - early trials

With the release of Glassfish 4 and J2EE version 7, I decided to work at upgrading my stamp web services application to the platform. An important part of my project is my 580 odd tests that include approximately 300 or so Arquillian tests. Since my application takes advantage of Container Managed transaction context and persistence providers, it is not sufficient for me to simply tests these in a out-of-container context. Afterall, how can I verify that listeners or cascading relationships cleanup correctly on a delete operation preventing orphans?

Problem with Latest Arquillian

In making the shift to Glassfish 4, I also upgraded the version of Arquillian and ShrinkWrap I was using and ran into essentially classpath hell. I figured my adventures were sufficient that I would blog about it.

First off, once I had it all working, I ran into a bug under Arquillian 1.1.1.Final. The exception was

WELD-001456 Argument resolvedBean must not be null

It turns out, there is an existing bug for this: . In order to workaround this bug, I needed to use Arquillian 1.0.3.Final.  Hopefully this will get fixed soon and I can move up.

Updates to pom.xml

So moving to what I changed (that is why you came here right?) lets start with the pom.xml. 

1. Since J2EE 7 uses a pretty recent version of Jersey for JAX-RS compliance, I modified my included Jersey dependencies from compile to provided. (The exception was jersey-client used in my tests that I might not need anymore with the latest JSR specs). I tied the version to the version in Glassfish 4 for compatibility (1.17)
   
2. I didn't think I would need eclipselink when testing with the embedded glassfish, but this turned out to be needed.  So for this I used the 2.5.0 version matching Glassfish 4.  As well, since I do not have a compile time dependency I changed the scope from provided to runtime.
   
   
         <dependency>
               <groupId>org.eclipse.persistence</groupId>
               <artifactId>eclipselink</artifactId>
               <version>${eclipselink.version}</version>
               <exclusions>
                   <exclusion>
                      <artifactId>commonj.sdo</artifactId>
                       <groupId>commonj.sdo</groupId>
                   </exclusion>
               </exclusions>
               <scope>runtime</scope>
           </dependency>
   
   
3. I was previously including the dependency org.eclipse.persistence.moxy to support MOXy in my application, but since this is the default provider now for Glassfish 4 JAXB processing (for JSON) I was able to remove it.
   
4. For the glassfish-embedded-all artifact, I switched to use 4.0.
   
5. Finally, in the surefire-plugin configuration, I had some classpath dependency exclusions. I had to add CDI to this or else Arquillian was bombing out (one of the JARs was bringing in a incompatible version of cdi-api). I found this using the netbeans maven plugin and the graphical display and this really helps. For reference here is the exclusions:
   

   
   <classpathDependencyExcludes>
     <classpathDependencyExcludes>javax.servlet:servlet-api</classpathDependencyExcludes>
     <classpathDependencyExcludes>org.apache.felix:javax.servlet</classpathDependencyExcludes>
     <classpathDependencyExcludes>javax:javaee-web-api</classpathDependencyExcludes>
     <classpathDependencyExcludes>javax.enterprise:cdi-api</classpathDependencyExcludes>
     <classpathDependencyExcludes>org.jboss.spec:jboss-javaee-web-6.0</classpathDependencyExcludes>
   </classpathDependencyExcludes>
   

6. Updated the version of ShrinkWrap to 2.0.0
   

I would provide the full pom.xml, but it is quite large (currently 508 lines) so I only included these snippets (also pygments.org is not up so I can not get nicely formatted code) .

Summary

Overall, this was a little more painful than I expected - although most of the pain came in the changes to ShrinkWrap and Arquillian versions that I thought I needed for GF4.   What compounded this was the sneaky inappropriate version of CDI that was causing all the dependency injection to fail.