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]
