On Oct 21, 2009, at 11:25 AM, Rick McGuire wrote:
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.
Hi Rick,
Agreed that whatever Servicemix/Aries build is doing would be a
problem... However, we do have a JTA spec -- https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jta_1.1_spec-1.1.1
Assume this can help address this problem in a reasonable way...
--kevan
