geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: NoClassDefError problem with geronimo-transaction bundle.
Date Wed, 21 Oct 2009 17:39:11 GMT

On Oct 21, 2009, at 8: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.

Can you provide a reference for the aries code?  Based on the  
servicemix spec bundles that repackage our spec jars I really doubt  
your analysis of what the bundle plugin is doing is correct.  Usually  
these use the felix maven-bundle-plugin to include all the classes  
from a geronimo spec jar together with some additional tweaks.

Also, AFAICT our geronimo-jta_1.1_spec jar includes all the  
javax.transaction* classes.  From a comment of Guillaume on the aries  
list I think he thinks these are the classes being included.

thanks
david jencks

>
> Rick


Mime
View raw message