Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Arquillian, Shrinkwrap and Seam 3: Q&A with Pete Muir, Principal Engineer at Red Hat

Arquillian, Shrinkwrap and Seam 3: Q&A with Pete Muir, Principal Engineer at Red Hat

This item in japanese

InfoQ recently caught up with Red Hat principal Software Engineer Pete Muir for a Q&A session about key JBoss projects he is involved with - Arquillian, which Muir started, and ShrinkWrap. We also touched on some of the plans for Seam 3.

Arquillian, an integration testing framework, is driven by the following concepts described on the project website :

  • managing the lifecycle of the container (start/stop)
  • bundling the test class with dependent classes and resources into a deployable archive
  • enhancing the test class (e.g., resolving @Inject, @EJB and @Resource injections)
  • deploying the archive to test (deploy/undeploy)
  • capturing results and failures.

Muir is involved with the JBoss Seam project - JBoss’s open source development stack - and was the project lead for the JSR-299 (the Context and Dependency Injection specification) reference implementation, Weld. Weld will also feature prominently in the upcoming Seam 3. Muir talked about how Arquillian fits into the development of Seam, and his vision for the future of the project. He explained how Arquillian leverages ShrinkWrap; an API that allows for programmatic archive/packaging generation into a variety of file formats which include JAR, EAR, and WAR.

InfoQ started the discussion with Muir about Arquillian, and competing technologies.

InfoQ: Please tell us how Arquillian differentiates itself from other Java EE Integration test frameworks such as Cargo, or older projects like EJBUnit?

Arquillian is built from the ground up on the idea of not forcing the user to learn yet another framework, but rather using what the developer already knows. When you write your tests, you write them based on your existing tools like JUnit, TestNG or JSFUnit. And when you're testing (for example) CDI, your test case feels like a CDI bean with support for @Inject and other CDI features. This way, the learning curve for starting to use Arquillian is very short, since you already know most of what you need to know.
The normal approach is to deploy your whole application and test against it. Yet, when it fails, you have no idea where it failed. With the help of ShrinkWrap, Arquillian gives you something you have never had before; fine grained control over your Java EE testing. You can test single EJB beans in isolation to make sure that part of your application works.
Arquillian is a modern approach to the age old Java EE component model testing problem. But when we look at the core of Arquillian, there is nothing that ties it to Java EE. Java EE is just one of the possible forms Arquillian can take. The Arquillian use case is to open up any container for inside testing. This in turn opens up for flavors like OSGi or Remote JVMs.

InfoQ: How has this project leveraged ShrinkWrap to further simplify the archival and deployment process? What role does ShrinkWrap play? Additionally, could you tell us a bit about it?

Traditional deployment in Java EE involves the use of file-based archives: EARs, JARs, and WARs. With the ShrinkWrap project, we enable users to bypass a formal build process and file serialization by providing a simple API to manipulate these structures. Deployment then becomes object-based; we send an instance of a ShrinkWrap archive to a backing container.

InfoQ: What role does Arquillian play in Seam 3?

Arquillian is a key member of the Seam stack, providing an end-to-end testing solution for any application built using the Seam stack. We also use Arquillian extensively to test all components of the Seam stack, as well as functionally test JBoss Application Server.
A number of the key innovations in Java Enterprise Edition 6 (such as CDI and Bean Validation) were led by JBoss; with the specification, a TCK (Technology Compatibility Kit), which verifies an implementation of the specification, must be delivered. From this work it quickly became apparent that a new approach to testing inside containers was necessary; initial prototyping led to Arquillian, and future releases of the TCKs will be built on Arquillian.

InfoQ: How can other community supported (Jetty, Tomcat, GlassFish, Geronimo) or commercial (WebLogic, WebSphere) servers be supported?

Seam 3 and Arquillian fully support any Java EE 6 (full or web profile, such as JBoss AS 6) certified container, popular servlet containers (such as Tomcat or Jetty), and offer preliminary support for cloud environments such as Google Application Engine. With Arquillian 1.0 we intend to offer support for the latest release of all popular application servers.


We wrapped up the session with a couple of questions regarding upcoming features to be added for Arquillian, and a brief note on another notable development at JBoss. Muir told us that when Arquillian 1.0 ships we should expect to see code coverage in any supported container using Cobertura, full OSGi support, and support for Maven Archetypes. Beyond 1.0 JBoss will be looking at full EL integration and tooling. JBoss is also working on GWT integration for Seam 3. Muir said

Coming up, we'll start to see GWT really take its place as a first-class option for writing your view layer. The GWT integration for Seam 3 will focus heavily on integration with Errai, which provides the necessary plumbing to export the CDI programming model directly into browser client code. Specifically, support for CDI eventing as well as first-class support for using Errai's messaging framework will allow developers to build rich, asynchronous web-based clients for their software that break free of the traditional constraints associated with most web frameworks.
Errai provides first-class support for object serialization, push messaging, straight-forward conversation management, as well as providing an in-browser IOC/DI framework that implements the JSR-330 specification and portions of the JSR-299 specification for the CDI integration. The result is client code that is Java-based, type-safe, and truly shares common APIs across server and client code.

Rate this Article