Hi Neil, Thanks for the explanation. I'm not sure how they "fixed" the issue in Karaf, but it contains Felix 4.0.3 and Aries 1.0... and it starts... :-) That is how far I got. I'll now try to get some Aries samples to work... Will post back if they run OK on out-of-the-box Karaf.
Thanks, Michiel ----------------- http://www.codessentials.com - Your essential software, for free! Follow us at http://twitter.com/#!/Codessentials ________________________________ From: Neil Bartlett <[email protected]> To: [email protected] Sent: Wednesday, November 21, 2012 8:42 AM Subject: Re: Differences between Felix 4.x and 3.x for javax classes Oh and for the folks who said "just use Karaf".... well, I first found this problem myself when helping a customer who was using Karaf. So it can definitely happen there as well. I'm not saying that Karaf is not good, but it's not a magic fix for every problem! Neil On Wed, Nov 21, 2012 at 7:37 AM, Neil Bartlett <[email protected]> wrote: > This unfortunately doesn't even solve the problem fully. Let me explain, > it's a bit complicated. > > First some background. The javax.transaction and javax.transaction.xa > packages were added to the JRE back in Java 5 (I think). They had > previously only been available as part of J2EE, but they were needed in the > JRE because they started to be referenced from the JDBC library in package > javax.sql. > > Unfortunately some absolute MORON decided to only include a subset of the > types from those packages in the JRE! For "normal" Java developers this > didn't matter too much because they could just put the full packages on > their classpath and continue working, but in OSGi we have a terrible > situation because we have a split package: the system bundle is exporting a > small subset of the package, and you have a proper bundle somewhere > exporting the full packages. In the past most people have worked around > this by being sure to import the "full" package by versioning their > import.... i.e. if you do Import-Package: > javax.transaction.xa;version=1.0.0 then you cannot get the subset package > from the system bundle. > > Now what changed in Felix 4.0 is that the system bundle exports packages > with correct uses-constraints. In particular it exports javax.sql with a > uses-constraint because javax.sql uses javax.transaction.xa... that is, it > exposes the javax.transaction.xa types through its public interfaces. This > is the absolutely correct and proper thing for Felix to do! However it > creates a problem because now any bundle that uses JDBC MUST also use the > system-bundle version of the javax.transaction(.xa) packages.... which are > broken. So this is the source of your uses-constraint violation. > > In my opinion the only way to fix this is to correct the original mistake > made by Sun, and add the missing types back into the system bundle > packages. This means taking the full transaction packages (I get them from > the Geronimo transaction spec JAR) and put them on the system classpath of > my OSGi framework launcher. I also add an additional export of > javax.transaction and javax.transaction.xa as version 1.0.0, so the system > bundle will be exporting both version 0.0.0 and version 1.0.0... this part > can be done with the org.osgi.framework.system.packages.extra property. > > Neil > > > On Wed, Nov 21, 2012 at 7:17 AM, David Jencks <[email protected]>wrote: > >> The problem with just not exporting any javax.transaction.[xa] from the >> framework is that some bits of the java runtime use the classes included (I >> think UserTransaction, but I don't recall). So you can get class cast >> exceptions. What the recommended thing to do is something like exporting >> from the framework >> >> javax.transaction; javax.transaction.xa; version=1.1; partial=true; >> mandatory:=partial, \ >> >> >> and then having a corresponding import-package statement with >> partial=true in the jta jar. I thought we had this in geronimo, so I'm not >> quite sure what's going on since it appears to be missing. >> >> You may just not run into any of these problems :-) >> >> david jencks >> >> On Nov 20, 2012, at 10:53 PM, Michiel Vermandel wrote: >> >> > Hi, >> > >> > I do not know what changed between 3.x and 4.x but I ran into the exact >> same issue the other day. >> > Richard S. Hall gave a solution/workaround to the issue. >> > This is what he posted yesterday (mail of 20/11/12 12.01): >> > >> > Probably the simplest thing to do is to try to eliminate >> > javax.transactions from the system bundle... >> > >> > To do this, you'll need to copy the org.osgi.framework.system.packages >> > property out of the default.properties file inside the felix.jar file >> > and put it into the conf/config.properties files...the value is quite >> big. >> > >> > It uses property substitution based on the JVM to set the value, but you >> > can just pick the value you want and then delete the transactions >> > package from it. >> > >> > I tried this approach and it did work. >> > Another - also working - alternative is - as Alexey Romanov proposed - >> to use Apache Karaf 2.3.0. >> > It has Felix 4.0.3 and Aries 1.0 on board. Integrated and nicely >> working out of the box. >> > >> > I hope you get up and running again with this info. >> > >> > Regards, >> > >> > Michiel Vermandel. >> > >> > ----------------- >> > http://www.codessentials.com - Your essential software, for free! >> > Follow us at http://twitter.com/#!/Codessentials >> > >> > >> > ________________________________ >> > From: Keith Hughes <[email protected]> >> > To: [email protected] >> > Sent: Wednesday, November 21, 2012 4:53 AM >> > Subject: Differences between Felix 4.x and 3.x for javax classes >> > >> > Hi folks, >> > >> > My application was using Felix 3.2.2. I am running under openjdk-6. >> > >> > I tried switching to Felix 4.0.3 and suddenly I was getting the message >> > >> > org.osgi.framework.BundleException: Uses constraint violation. Unable to >> > resolve bundle revision org.apache.openjpa [22.0] because it is exposed >> to >> > package 'javax.transaction.xa' from bundle revisions >> > org.apache.geronimo.specs.geronimo-jta_1.1_spec [45.0] and >> > org.apache.felix.framework [0] via two dependency chains. >> > >> > Chain 1: >> > org.apache.openjpa [22.0] >> > import: >> > >> (&(osgi.wiring.package=javax.transaction.xa)(version>=1.1.0)(!(version>=1.2.0))) >> > | >> > export: osgi.wiring.package=javax.transaction.xa >> > org.apache.geronimo.specs.geronimo-jta_1.1_spec [45.0] >> > >> > Chain 2: >> > org.apache.openjpa [22.0] >> > import: >> > >> (&(osgi.wiring.package=javax.persistence.spi)(version>=1.1.0)(!(version>=2.1.0))) >> > | >> > export: osgi.wiring.package=javax.persistence.spi; uses:=javax.sql >> > com.springsource.javax.persistence [43.0] >> > import: (&(osgi.wiring.package=javax.sql)(version>=0.0.0)) >> > | >> > export: osgi.wiring.package=javax.sql; uses:=javax.transaction.xa >> > export: osgi.wiring.package=javax.transaction.xa >> > org.apache.felix.framework [0] >> > >> > It appears I am getting javax.transaction from two different bundles and >> > Felix can't pick. >> > >> > If I look at bundle 0 if using gogo shell, I see that it is exporting >> > javax.transaction both in Felix 3.2.2 and 4.0.3. But for some reason it >> > comes up with this clash in 4.0.3. What gives? >> > >> > I tried changing the org.osgi.framework.bundle.parent property when I >> > started up Felix. I tried all the legal values, boot, app, ext, and >> > framework in case that was the issue, but I got the same result every >> time. >> > >> > So what changed between 3.x and 4.x that I would start seeing this >> problem? >> > Is there some configuration setting I could use to tell Felix to use a >> > bundle supplier that isn't bundle 0? >> > >> > Thanks, >> > -Keith >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
