First, the javax.transaction classes from aries are the ones from geronimo. They come from a transitive mavne dependency.
Second, your class loader issue can be solved as we did in ServiceMix / Karaf. The first trick I used is to configure the system bundle so that it does not export the javax.transaction pacakge. It seem doing so can still lead to problems when using JDBC with XA, so the correct hack can be found in: https://svn.apache.org/repos/asf/felix/trunk/karaf/assembly/src/main/filtered-resources/etc/config.properties Mainly those lines: org.osgi.framework.bootdelegation=sun.*,com.sun.*,javax.transaction,javax.transaction.* javax.transaction; javax.transaction.xa; partial=true; mandatory:=partial, \ We (Aries or ServiceMix) don't ship sun classes, but the geronimo ones. Everything else is classloading issues. On Wed, Oct 21, 2009 at 17:25, Rick McGuire <rick...@gmail.com> 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. > > Rick > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
