I noticed. I think that using boot delegation is a not a good solution. It essentially means that in your environment javax.transaction does not need to be imported which is likely to inhibit portability if you rely on it. I think setting the org.osgi.framework.system.packages.extra to export javax.transaction at 1.1 is a better and more OSGi friendly approach.
Alasdair On 5 March 2010 08:07, Guillaume Nodet <[email protected]> wrote: > I've gone ahead and change back to the previous state. > I've made one change though which is to have the bundle export and > import the javax.transaction.* packages. > This should allow both ways to work, i.e. > * have your system bundle exporting the javax.transaction package > with version 1.1 and have jta api in the system classpath > * boot delegate javax.transaction.* package and add a mandatory > attribute on those pacakges exported by the jre > > On Fri, Mar 5, 2010 at 00:48, Guillaume Nodet <[email protected]> wrote: >> Why did you change that behavior ? >> Did you set up your environment to boot delegate and add the mandatory >> attribute on the transaction packages on your system bundle ? >> This is the way it is supposed to work. >> See the follwoing config file for example: >> >> http://svn.apache.org/repos/asf/felix/trunk/karaf/assembly/src/main/filtered-resources/etc/config.properties >> >> On Fri, Mar 5, 2010 at 00:12, Brian De Pradine <[email protected]> wrote: >>> Hi Joe, >>> >>> The main change to the transaction implementation is that the >>> org.apache.aries.transaction.manager bundle no longer exports the >>> javax.transaction and javax.transaction.xa packages. This means that in >>> order to use transactions you now need to add the >>> geronimo-jta_1.1_spec-1.1.1.jar to the bootclasspath. The reason that this >>> is necessary is that the system bundle also has some classes from the >>> javax.transaction and javax.transaction.xa packages and using those >>> classes results in errors similar to the following: >>> >>> java.lang.LinkageError: loader constraint violation: when resolving >>> interface method >>> "javax.sql.XAConnection.getXAResource()Ljavax/transaction/xa/XAResource;" >>> the class loader (instance of >>> org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader) of the current >>> class, org.apache.aries.transaction.jdbc.ConnectionWrapper, and the class >>> loader (instance of <bootloader>) for resolved class, >>> javax/sql/XAConnection, have different Class objects for the type >>> javax/transaction/xa/XAResource used in the signature >>> >>> You probably haven't seen this exception before when running the Aries >>> Trader application because the code to enlist JDBC resources in >>> transactions is also included in the same patch. >>> >>> On 4 March 2010 18:06, Joe Bohn <[email protected]> wrote: >>>> Hi Alasdair, >>>> >>>> Thanks. ?I'm sorry if my note sounded a little terse and you thought I >>> was >>>> complaining about the jndi issue (or even the transaction issue for that >>>> matter). ?That was not what I intended to convey. >>>> >>>> My note was more driven by confusion related to transaction support. ?I >>> just >>>> confirmed (at least as far as I understand how to do) that AriesTrader >>>> transaction support was working prior to the recent changes. ?However, >>> I've >>>> heard comments that it should not have been working. And so I was trying >>> to >>>> get a better understanding of why it was working before and if the >>> recent >>>> changes (which now require adding the geronimo jta spec to the >>>> Xbootclasspath) were really necessary. >>>> >>>> The jndi change was really just mentioned because you can't get far >>> enough >>>> in AriesTrader to see transaction working unless you also revert the >>> jndi >>>> change locally which will let you get far enough to see it working with >>> the >>>> former transaction code. >>> >>> >>> Cheers >>> >>> Brian DePradine >>> Web Services Development >>> IBM Hursley >>> External +44 (0) 1962 816319 Internal 246319 >>> >>> If you can't find the time to do it right the first time, where will you >>> find the time to do it again? >>> >>> >>> >>> >>> >>> >>> Unless stated otherwise above: >>> IBM United Kingdom Limited - Registered in England and Wales with number >>> 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >>> >>> >>> >>> >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Blog: http://gnodet.blogspot.com/ >> ------------------------ >> Open Source SOA >> http://fusesource.com >> > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
