On Oct 21, 2009, at 9:50 AM, Kevan Miller wrote:
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...
Along with my belief that this aries bundle is actually repackaging
the geronimo jta spec jar, I'll note that I ran into big problems in
the connector_1.6 build with getting the jta classes available from
the bundle rather than the jvm. I solved it in the build by putting
the jta spec jar in the maven classpath, which is a really bad solution.
guillaume says he's solved this with a trick from the glassfish guys
in karaf/servicemix. We don't really understand how it works, but it
forces loading javax.transaction classes from the framework when
available but prevents any bundle wiring to the framework for them.
You seem to need a property like this:
org
.osgi
.framework
.bootdelegation=sun.*,com.sun.*,javax.transaction,javax.transaction.*
and a framework exports clause something like this:
javax.transaction; javax.transaction.xa; partial=true;
mandatory:=partial,
I'm hopeful that the same trick can be used in our build.
thanks
david jencks
--kevan
