Drools with OSGi and the ambiguous org.drools.concurrent package

If you’re using Drools 5.4.x – 5.5.x inside an OSGi container and getting the below error then you’ve probably hit the same bug as me (documented here) :

java.lang.ClassNotFoundException: org.drools.concurrent.ExecutorProviderImpl

Drools 5.4 and 5.5 have caused quite a hassle when integrating with one of my OSGi bundles. The problem stems from two required Drools bundles – drools-core and drools-api. Both of these bundles export the same package, one has a required class, the other doesn’t and as you’ll be wanting the same version for both drools-core and drools-api the OSGi container has a hard time distinguishing which package to use.

The package in question is org.drools.concurrent. The package from drools-api doesn’t have ExecutorProviderImpl whilst drools-core does.

The solution is to merge the org.drools.concurrent package from both drools-api and drools-core. This means you’ll need to repackage the org.drools.api bundle or edit the MANIFEST.mf file of this bundle and force a dependency on the core bundle (org.drools.core) using the Require-Bundle OSGi attribute. This will aggregate these packages together allowing the correct resolution of the ExecutorProviderImpl class.

Require-Bundle: org.drools.core

Using Require-Bundle is deprecated (you should opt for having unique package names) but when you’re dealing with third party libraries the package naming is out of your control; there’s no other solution. Ideally packages should be named not only on the inverted domain name (com.theendian) but also have their bundle/project/jar name appended (com.theendian.mybundle) which should enforce identity on all packages.

Leave a Reply

Your email address will not be published. Required fields are marked *