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


Executable jar with TomEE and Tomcat Maven Plugin

Tomcat Maven plugin has a goal to allow you to create an executable jar: http://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/exec-war-mojo.html

It is nice but integrated with Tomcat so if you do JavaEE it doesn’t work…excepted if you use TomEE.

Continue reading


TomEE and ActiveMQ webconsole

ActiveMQ webconsole allows you to see broker information from a webapp. You can send and see messages for queues, topic…

However not sure it is due to a refactoring but last version doesn’t work well in TomEE. Looking further you realize there are some issues with activemq-webconsole packaging too (hope this will be fixed with next version).

However a simple workaround exists:

Continue reading