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] > > > > >> > > > > >> > > > > > > > > > > > > > > >
