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