OK, great command. Thanks. So when I used inspect I saw that it wasn't wiring to javax.transaction anywhere, though it was wiring to javax.sql from the framework bundle. I upgraded openjpa to 2.3.0 wondering if perhaps they had fixed something in there, same problem. So I looked at the import on the bundle itself and it was asking for javax.transaction 1.1.0, though I had declared it 1.0.0 when I added it to extra packages. I fixed that and everything worked.
Wow, this whole javax stuff is annoying. I wish Sun had made the right decisions. Thanks for your help Neil, I much appreciate it! On Fri, Dec 20, 2013 at 3:28 PM, Keith Hughes <[email protected]>wrote: > Cool, thanks Neil, will let you know. > > Hopefully at this point it just becomes me figuring it out and thanking > you for the support, and not more questions. > > I love OSGi, but it is a tad opaque at times. But I learn more all the > time. It certainly has made my use case possible, so I am very happy about > that. > > > > On Fri, Dec 20, 2013 at 2:23 PM, Neil Bartlett <[email protected]>wrote: > >> Yes I'm still here... :-) >> >> It sounds like you're doing basically the right thing. If the openjpa >> bundle isn't loading the class then you should first check whether it's >> actually wired to the export from the system bundle, or to somewhere else. >> Assuming you are running the Gogo shell you can get this information by >> typing: >> >> inspect req osgi.wiring.package <ID> >> >> where <ID> is the bundle ID of the openjpa bundle. This command will list >> all the package requirements of the bundle along with the corresponding >> export that they have been wired to. If you have trouble interpreting the >> output then paste it into a reply to this thread. >> >> Regards >> Neil >> >> >> On Fri, Dec 20, 2013 at 8:59 PM, Keith Hughes <[email protected] >> >wrote: >> >> > Neil, >> > >> > I know this is an old thread by now, but hopefully you will see this. >> > >> > So I am finally trying to make this work. At the time I last sent this I >> > had a deadline to get a production version out so just stuck with Felix >> > 3.x. But now I have time. >> > >> > The way my system starts up is that I start up the JVM with only one of >> my >> > jars. That jar contains a single class which scans a directory for all >> of >> > the jars in it and creates a classloader with those jars on its >> classpath. >> > >> > I then create an instance of the class that starts the OSGi framework >> from >> > this classloader using newInstance. >> > >> > One of the jars that is put on this classpath for this created >> classloader >> > is the geronimo JTA jar (geronimo-jta_1.1_spec-1.1.1.jar). >> > >> > I then set the framework extra system packages property to include >> > >> > javax.transaction; version=1.0.0, javax.transaction.xa; version=1.0.0, >> > javax.transaction, javax.transaction.xa >> > >> > So now the geronimo JTA classes are on the classloader of my framework. >> > >> > Now I don't see the problem I saw in the first email of this thread with >> > the two dependency chains, now I see that openjpa cannot find things >> like >> > javax.transaction.Synchronization. So perhaps the dependency problem has >> > gone away merely because I can no longer see the classes at all. >> > >> > I can see it on the framework's classloader, useing >> > framework.loadClass("javax.transaction.Synchronization"). I tried >> playing >> > with setting the bundle classloader parents, may have to try that again >> to >> > see if I screwed anything up. >> > >> > -Keith >> > >> > >> > >> > On Wed, Nov 21, 2012 at 3:00 AM, Neil Bartlett <[email protected]> >> > wrote: >> > >> > > 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] >> > > > >> >> > > > >> >> > > > > >> > > > >> > > >> > >> > >
