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

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!

Continue reading


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"
            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" />

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).

Continue reading


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…).

Continue reading


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.

Continue reading


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.

Continue reading


Java 8 default interface methods and JDK dynamic proxies

Java 8 added the ability to support default methods in interfaces.
That’s great for a lot of reasons and it works fine but what about
dynamic proxies? Are the default method skipped when needed? Are they
forwarded to the invocation handler?

Well JVM is well done and it is forwarded to the InvocationHandler. It
means your invocation handler invoke(proxy, method, args) method is
invoked when calling an interface method with a default….which
sounds logical since after all that’s an interface method.

When you use proxies to fully decorate an existing instance no issue,
if you call the default method your proxy will call the same method on
the delegate instance and if it should use the default it will….but
if you hack the proxy to implement it on the
fly without any delegate how to do?

In this case you know that if a method is a default one you need to
call the default implementation of the interface. Here are two issues:

  1. how to know a method is a default one?
  2. How to call the default implementation?

First issue is easy to solve, Java 8 added to its reflection API
java.lang.reflect.Method.isDefault(). Side note is you can check it in
previous java versions too backporting its implementation to an
utility method:

public boolean
isDefault() {
  return ((getModifiers() & (Modifier.ABSTRACT | Modifier.PUBLIC | Modifier.STATIC)) ==
          Modifier.PUBLIC) &&

The second issue is a bit more complex. If you call
method.invoke(proxy, args) you’ll loop in the proxy since the proxy
will try to invoke the real method which is the proxy one actually.

To workaround it you need to use java 7 new invoke API (MethodHandle).
The methods to have a look are the *Special ones which basically skip
the overriding checks.

Here how to do:

  .unreflectSpecial(method, declaringClass)

First step is to get a lookup (kind of method handle factory), then
force the declaring class (default is caller class), unwrap the
java.lang.reflect.Method to a “special” MethodHandler and finally
invoke it on the proxy. Since it is “special” it will skip the
overriding done by the proxying and invoke the default implementation

Here what the InvocationHandler finally looks like:

InvocationHandler handler = (proxy, method, args) -> {
if (method.isDefault())
final Class<?> declaringClass = method.getDeclaringClass();
.unreflectSpecial(method, declaringClass)

// proxy impl of not defaults methods
return null;

This opens several interesting doors. For instance with EJBs you could – if the spec goes this way – decorate an interface default method with @Asynchronous and return an AsyncResult just wrapping the other method. This way you get for all implementations asychronous calls for free from the implementations point of view.

Where it can go weird is if you can inject in parameters CDI beans or any injectable EE resources…then you don’t need classes anymore ;).


Java 8 repeatable annotation: will it change JavaEE 8?

Not sure you noticed it since some changes are more important in java 8 but you can now repeat annotations. What does it mean?

Basically if we suppose you have this annotation:

Continue reading


java -jar my-app-in-tomee.jar

Starting Tomcat, TomEE or OpenEJB is quite simple, basically a single script to run….but a script. Sometimes in production you can’t use bash or something else and these scripts can be broken in the shell you have access to.

Another point can be the normalisation in the enterprise of runners: all java apps should be runnable with java -jar app.jar.

Well globally sometimes you need a jar to run TomEE. If you read my previous posts you know there are few solutions but nothing very simple.

That’s why TomEE Maven Plugin now supports an exec goal.

Continue reading


TomEE, CDI and LoginModule

JAAS is not the best security framework it exists but it is often enough for simple needs. Once you passed the setup (I’ll not detail it here) it is generally nice to use. However when writing a CDI app you need to do the bridge yourself.

You can hook it up with DeltaSpike BeanProvider but it is not that obvious/fluent.

Continue reading