geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <>
Subject Re: NoClassDefError problem with geronimo-transaction bundle.
Date Wed, 21 Oct 2009 16:50:02 GMT

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 --

  Assume this can help address this problem in a reasonable way...


View raw message