First of all I think we should lean on felix to provide a 1.0 package
version for their tx classes.
Second without the split-bundle lin suggests wont' there be this
problem anyway since the system bundle will have used up the packages
and ours will be ignored?
thanks
david jencks
On Jun 10, 2009, at 10:58 AM, Jarek Gawor wrote:
Hey all,
I'm experimenting with JPA (OpenJPA specifically) in osgi environment
and I ran into an interesting issue with the transaction API. The root
of the problem is that the JDK provides a *subset* of the
javax.transaction classes that the JTA specification defines. And that
creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
depending on which bundle is used to wire in the transaction packages.
The JVM transaction packages are exported via the system bundle (just
like any other JVM package). On Felix, the JVM packages are exported
with the version of the JVM you are running on (e.g. if you are
running Java 5, the version attribute is set to 1.5.0). Our JTA spec
bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
with version 1.1.0.
Now, openjpa has the following javax.transaction imports:
javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
On Felix, the container wires these imports using the system bundle
since the system bundle exports these packages with higher version
then the JTA bundle and that creates the NoClassDefFoundError
problems. So, one would think that updating the version in our JTA
spec bundle to something higher then 1.5 or 1.6 should work. And I
think that should work but it doesn't seem to be working right on
Felix. I don't know if this is a bug or if I'm just missing something
or doing things wrong. When I install the openjpa bundle for the first
time, its transaction imports get wired to our JTA bundle. But once I
restart Felix, the openjpa transaction imports are wired to the system
bundle.... maybe somebody knows what's going on here?
Interestingly enough, Equinox exposes the JVM packages with version
0.0.0 and so I don't run into these NoClassDefFoundError errors there.
One thing that worked for me reliably is when I updated the JTA spec
bundle to be a fragment bundle (attaching itself to the system
bundle). That way, the missing transaction classes can be loaded
through the system bundle classloader. So, I'm wondering if we should
turn the JTA spec bundle into a fragment bundle (just manifest
updates) to deal with this problem?
Jarek
