I spent a little time looking into this problem this morning, and
uncovered a couple of issues that need discussing. Essentially, the
problem here is that the javax.transaction and javax.transaction.xa
class are loaded off of the system class path with prior releases of
Geronimo. However, when you are dealing with bundles, packages on the
system class path are not automatically part of the class loader
wiring. Classes on the system class path are part of the system bundle,
but only if they have been explicitly included as part of the framework
configuration.
I took at look at the transaction component that was contributed to the
Aries project for some ideas on how this might be solved. It appears
this component is taking advantage of some support in the bundle plugin
to fix this problem. In the bundle configuration, the
javax.transaction.* packages are defined in the exports. This
information causes the class files from the build classpath to be
included in the bundle and the generated manifest both imports and
exports these classes. The bundle thus provides these classes directly
rather than loading the ones directly from the JRE.
I think that this practice is one some fairly shaking licensing ground.
Those class files are Sun licensed entities (assuming the , and I'm not
sure that an Apache project can legally redistribute these classes
separate from the rest of the JVM. Additionally, this essentially means
that the version of these classes used depends upon the person who
actually builds the release artifacts. I'm not sure this is a real
concern, but it's enough to make me nervous.
So, what are the potential solutions?
1) Make sure our framework configuration adds javax.transaction and
javax.transaction.xa to the system bundle configuration.
2) Use the export technique from the Aries version, but ensure that the
embedded class files are appropriately Apache licensed.
I see that we don't have a specs release for the javax.transaction.*
classes. It might be time to create a set. I suspect this is not
terribly difficult to do, since I think these are all just interfaces
and exception classes.
Rick
- NoClassDefError problem with geronimo-transaction bundle. Rick McGuire
-