geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <rick...@gmail.com>
Subject NoClassDefError problem with geronimo-transaction bundle.
Date Wed, 21 Oct 2009 15:25:31 GMT
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

Mime
View raw message