Integration Testing for JBoss AS7, Tomcat and Weld SE

Initially, the jeeunit Integration Testing framework was exclusively focused on Java EE 6, supporting GlassFish 3.x, which was the only Java EE 6 compliant server at that time. Support for Resin 4.x has been added in subsequent releases.

With the current release 0.9.1, jeeunit supports JBoss AS 7, as well as alternative containers and injection methods beyond the scope of Java EE 6. You can now run jeeunit tests on Tomcat 6 and 7 and Weld SE containers.

Tomcat can be combined either with Spring 3.1 or with CDI (Weld Servlet) to inject dependencies into jeeunit tests.

And there's more to come: While jeeunit will continue a life of its own for a while, I'm planning to merge it step by step into Pax Exam, the OSGi testing framework of the OPS4J community.

Pax Exam and jeeunit both implement an in-container testing approach - while Pax Exam focuses on OSGi alone, jeeunit now supports various other containers, but no OSGi at all.

The Pax Exam/jeeunit merger opens interesting perspectives for hybrid applications, i.e. enterprise applications composed of traditional WARs and OSGi bundles. GlassFish 3.x supports this hybrid application model, implementing a subset of the OSGi Enterprise specifications.

For Pax Exam, the road towards the next major release 3.0.0 will be marked by a sequence of milestone releases, each of which is to incoporate a new container adapted from jeeunit.

A Pax Exam GlassFish Test Container is the goal of the first proof-of-concept milestone 3.0.0.M1. This is work in progress on a dedicated branch exam3-milestones in the Pax Exam GitHub repository.

Stay tuned...

Troubleshooting VisualVM Remote Connections

I was trying to use VisualVM to monitor the memory usage of a build job on our build server. According to the documentation, this should require nothing but a jstatd daemon running on the remote machine.

For some reason, I could not see any remote applications in my local VisualVM. It was not a port issue, all the required ports were reachable via telnet.

Googling around, this article finally gave my the important clue: Our network does not have consistent DNS names, so I had to connect to the remote machine via IP address. Setting the java.rmi.server.hostname property for jstatd to the IP address solved the problem.

Summary

On the remote machine

Create policy file for jstatd

grant codebase "file:${java.home}/../lib/tools.jar" {
    permission java.security.AllPermission;
};

Start jstatd with this hostname file and the IP address as hostname

jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=192.168.0.123

On the local machine

Start jvisualvm and add a Remote Host with the given IP address. A jstatd connection will be established by default. You should now see your remote applications.