Yes I'm aware that Karaf does at least start. However just because you haven't seen the problem doesn't mean it no longer exists.... it can still occur if you install a particular set of bundles with a bad combination of imports.
Since this is a complicated issue and one that does occur from time to time, I intend to write a page on the OSGi Community Wiki documenting the problem and my proposed solution. Neil On Wed, Nov 21, 2012 at 9:08 AM, Michiel Vermandel <[email protected]>wrote: > 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] > >> > >> > > >
