geronimo-dev mailing list archives

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

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

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

and a framework exports clause something like this:

javax.transaction; javax.transaction.xa; partial=true;  

I'm hopeful that the same trick can be used in our build.

david jencks

> --kevan

View raw message