EJBContainer and JUnit rules, no more need of any Runner! Thanks OpenEJB!

If you read this post you surely know some “common” ways to test EE applications with JUnit using a runner. It often looks like:

@RunWith(CdiTestRunner.class)
public class MyEETestWithDeltaSpike {
    @Inject
    private ACdiBean bean;

    @Test
    public void theTest() {
        // do test
    }
}

or

@RunWith(EJBContainerRunner.class)
public class MyEETestWithOneOpenEJB {
    @Inject
    private ACdiBean bean;

    @Test
    public void theTest() {
        // do test
    }
}

These tests have something in common: they use the classpath to deploy and don’t need something else (compared to Arquillian or ApplicationComposer).

That’s great but you bind your test lifecycle to the specific runner. It means you can’t compose runners and you can’t do anything before the container bootstrap like starting a FTP server with rule-them-all or just using JUnit Theories or Parameterized runners.

Advertisement

EJBContainerRunner or test with EJBContainer easily

To test a EE application you have several solutions. One of them is to use EJBContainer.

EJBContainer container = EJBContainer.createEJBContainer(properties);
// do test
container.close();

These steps are often in a test lifecycle (@BeforeClass/@AfterClass for JUnit for instance).

With OpenEJB you also have:

container.getContext().bind("inject", this);

This allows you to get injections (@Inject, @Resource, @PersistenceContext…) in the test class.

That’s nice but you can make it easier!

TomEE makes JMXMP usage simple

Tomcat includes out of a box a Listener to simplify JMX usage but it mainly handles default connector – JVM one).

Often in enterprise you need to use another one. The most known is JMXMP.

To make it easy to use in TomEE, you can now use JMXServerListener.

Just add in your server.xml this new listener:

<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
  <Listener className="org.apache.tomee.catalina.ServerListener" />

  <!-- this listener will handle jmxmp server lifecycle -->
  <Listener className="org.apache.tomee.loader.listener.JMXServerListener"
            protocol="jmxmp"
            host="localhost"
            port="1234" />

  <Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000" />

    <Engine name="Catalina" defaultHost="localhost">
      <Host name="localhost"  appBase="webapps"
            unpackWARs="true" autoDeploy="true" />
    </Engine>
  </Service>
</Server>

You can of course configure the host, port, potentially urlPath and the protocol. Note if you don’t provide the protocol jmxmp will be used.

Now to make it working you need to add jmxmp to the container. It is provided as a jar (you can find several ones on the internet). I used org.glassfish.external:opendmk_jmxremote_optional_jar:1.0-b01-ea. To make it easier I added it using TomEE container provisioning feature.

Just create a file conf/provisioning.properties with the line:

jar = mvn:org.glassfish.external:opendmk_jmxremote_optional_jar:1.0-b01-ea

Now you can start TomEE :).

When it starts it logs somethings like:

Infos: Started JMX server: service:jmx:jmxmp://localhost:1234

JMXMP is not in the JVM (that’s why we added a jar to TomEE) so to connect with a client (JConsole, JVisualVM, JMC…) you need to add this jar as well.

Here is a sample for JConsole:

java -cp $JAVA_HOME/lib/jconsole.jar:$CATALINA_HOME/additionallib/opendmk_jmxremote_optional_jar-1.0-b01-ea.jar sun.tools.jconsole.JConsole service:jmx:jmxmp://localhost:1234

Use two oracle JDBC drivers in TomEE without conflicts

Sometimes you write an application relying on multiple datasources

While they use different drivers (I mean different database driver) or the same version it is fine but when it is not the case what to do? (let take the exemple of two not compatible Oracle drivers).

OpenEJB/TomEE custom DataSource JTA integration

OpenEJB and TomEE provide default factories for datasources allowing to define easily by configuration JTA or not datasource pooled by a configurable pool implementation (dbcp, tomcat-jdbc, bonecp…).

But sometimes it is not enough. You want to take the control of the datasource (if you want to use native driver pooling, read the config from a custom source etc…).

DTO to domain converter with Java 8 and CDI

DTO is often the thing we don’t want to do but it is actually quite important to get them to be able to make the application evolving without breaking everything each time.

The main difficulties is you often need a unitary convert method from DTO to domain and another one for lists, maybe one for map…and this for each resource you have. Using inheritance for it works but then you have a technical inheritance which then prevent you to get real inheritance in Java.

That’s why it is nice to use something else.

Apache Sirona and Java 8

Java 8 went out few weeks ago and the question of monitoring is already here. Apache Sirona has several monitoring/interception flavors like CDI, Spring, JavaAgent…but the most interesting is the javaagent which doesn’t mandate to be integrated with a particular technology.

Since it instruments bytecode the question of Java 8 compatibility is important.