You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Keith Hughes <ke...@gmail.com> on 2013/12/20 21:59:41 UTC
Re: Differences between Felix 4.x and 3.x for javax classes
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 <nj...@gmail.com> 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 <mvermand@yahoo.com
> >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 <nj...@gmail.com>
> > To: users@felix.apache.org
> > 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 <nj...@gmail.com>
> > 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 <david_jencks@yahoo.com
> > >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 <ke...@gmail.com>
> > >> > To: users@felix.apache.org
> > >> > 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: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> >
>
Re: Differences between Felix 4.x and 3.x for javax classes
Posted by Keith Hughes <ke...@gmail.com>.
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 <ke...@gmail.com>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 <nj...@gmail.com>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 <keith.mhughes@gmail.com
>> >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 <nj...@gmail.com>
>> > 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 <
>> mvermand@yahoo.com
>> > > >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 <nj...@gmail.com>
>> > > > To: users@felix.apache.org
>> > > > 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 <
>> njbartlett@gmail.com>
>> > > > 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 <
>> > david_jencks@yahoo.com
>> > > > >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 <ke...@gmail.com>
>> > > > >> > To: users@felix.apache.org
>> > > > >> > 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: users-unsubscribe@felix.apache.org
>> > > > >> For additional commands, e-mail: users-help@felix.apache.org
>> > > > >>
>> > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: Differences between Felix 4.x and 3.x for javax classes
Posted by Keith Hughes <ke...@gmail.com>.
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 <nj...@gmail.com> 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 <keith.mhughes@gmail.com
> >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 <nj...@gmail.com>
> > 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 <mvermand@yahoo.com
> > > >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 <nj...@gmail.com>
> > > > To: users@felix.apache.org
> > > > 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 <njbartlett@gmail.com
> >
> > > > 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 <
> > david_jencks@yahoo.com
> > > > >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 <ke...@gmail.com>
> > > > >> > To: users@felix.apache.org
> > > > >> > 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: users-unsubscribe@felix.apache.org
> > > > >> For additional commands, e-mail: users-help@felix.apache.org
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Differences between Felix 4.x and 3.x for javax classes
Posted by Neil Bartlett <nj...@gmail.com>.
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 <ke...@gmail.com>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 <nj...@gmail.com>
> 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 <mvermand@yahoo.com
> > >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 <nj...@gmail.com>
> > > To: users@felix.apache.org
> > > 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 <nj...@gmail.com>
> > > 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 <
> david_jencks@yahoo.com
> > > >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 <ke...@gmail.com>
> > > >> > To: users@felix.apache.org
> > > >> > 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: users-unsubscribe@felix.apache.org
> > > >> For additional commands, e-mail: users-help@felix.apache.org
> > > >>
> > > >>
> > > >
> > >
> >
>