Test a particular CDI Extension with OpenEJB ApplicationComposer

OpenEJB ApplicationComposer is an old but very efficient way to test EE code. The idea is almost the same as with ShrinkWrap and Arquillian but with a big difference: it is performance oriented and embedded only. As a quick reminder to use the ApplicationComposer (either the JUnit runner or the abstract TestNG class) you just define a test class with a set of @Module methods declaring the in memory EE model (WebApp for web.xml, Beans for beans.xml, EjbJar for openejb-jar.xml, @Classes for scanned classes…) and standard @Test methods. Of course injections work in the test class. For instance:

public class MyTest {
  public EjbJar application() throws Exception {
    return new EjbJar()
            new SingletonBean(MyBean.class).localBean());

  private MyBean bean;

  public void myTest() {
    assertEquals("test", bean.myMethod());

That’s great but CDI extension mecanism still relies on classloader and since you use test classloader (Application loader) you’ll get into the test all available extensions…even web extensions you don’t want for your test for instance.

To avoid it ApplicationComposer got @CdiExtensions annotation. You put it on the class and list the extensions you want to take into account for the test:

@CdiExtensions({ MyExten.class, MyExt2.class })
public class MyTest2 {
  // ...

This is really useful when you rely on extensions which don’t work in embedded mode (web extension typically).

The other advantage to do it is to be able to test few CDI extensions without having to register them (META-INF/services/javax.enterprise.inject.spi.Extension is optional with this feature). This last feature is really useful when you extend abstract extensions.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s