Re: NoClassDefError problem with geronimo-transaction bundle.

[Rick McGuire <ri...@gmail.com>]

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.
D'oh, we already have a geronimo-jta spec.  I was looking for a 
geronimo-transaction one.  I think the solution here is just to make 
sure the jta spec if part of the build classpath and export the jta 
classes from the transaction manager bundle.   This may be fairly simple 
to solve.

>
> Rick
>