OSGi and Bitronix

[Dave W.]

Is anyone else using Bitronix in an OSGi environment? I was able to embed BTM in a bundle and export UserTransaction as a service, but as the ContextClassLoader is undefined in OSGi, I had to replace several uses of Thread.currentThread().getContextClassLoader().loadClass() with getClass().getClassLoader().loadClass() in order to load classes through my bundle classloader which imports needed packages from other bundles (my oracle driver bundle, JTA, etc).

Would it be possible to patch Bitronix to be more OSGi friendly, perhaps by trying the current classloader and falling back to the context classloader as needed?

[Ludovic Orban]

BTM is primarily made for J2SE and J2EE, OSGi support is only considered as nice to have.

That being said I think you can get BTM working fine without having to patch it thanks to some non-standard extension of some OSGi containers. Equinox' context finder comes to my mind but other implementations have equivalent features I suppose.

I'm also not against the idea of creating a configuration setting to switch between context's classloader and current class' classloader (or whichever else) but I'm not sure this is the way to go as most people would certainly overlook such parameter.

If you can come up with a bullet-proof solution I'll consider it.

[Dave W.]

Ludovic Orban wrote:

BTM is primarily made for J2SE and J2EE, OSGi support is only considered as nice to have.

Right, and just to be clear, I'm looking to make BTM more OSGI-friendly not to turn it into an OSGi bundle. There are other issues involved with driver package visiblity that I think would best be solved by embedding BTM in a custom bundle to suit the environment. We just need a small adjustment to classloading to enable this.

Ludovic Orban wrote:

That being said I think you can get BTM working fine without having to patch it thanks to some non-standard extension of some OSGi containers. Equinox' context finder comes to my mind but other implementations have equivalent features I suppose.

I'm currently developing with Equinox, but I have a goal of avoiding being locked into a particular implementation. Usually, I can manage by employing the idiom of temporarily replacing the context class loader with the bundle class loader when calling out to "unfriendly" libraries. Unfortunately, this does not suffice for BTM as the database driver classes are loaded when connections are requested from the pool. Altering BTM's classloading strategy to be more flexible is the least complex solution.

Ludovic Orban wrote:

I'm also not against the idea of creating a configuration setting to switch between context's classloader and current class' classloader (or whichever else) but I'm not sure this is the way to go as most people would certainly overlook such parameter.

If you can come up with a bullet-proof solution I'll consider it.

Looking at other opensource projects, the common strategy appears to be to move class and resource loading to a static utility class with static methods which check the context class loader and fall back to the current class loader. Centralizing the classloading process makes it easier to tweak and the fall back strategy allows the library to work in a variety of configurations without requiring an additional setting.
Does that sound reasonable for BTM?

[Ludovic Orban]

What you're proposing sounds like a reasonably minor change so if you open a JIRA issue and attach a patch, I'll merge it immediately.

If you can't provide a patch, I'll implement this change as time permits.