You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jarek Gawor <jg...@gmail.com> on 2009/06/10 19:58:03 UTC
jta spec bundle issue in felix
Hey all,
I'm experimenting with JPA (OpenJPA specifically) in osgi environment
and I ran into an interesting issue with the transaction API. The root
of the problem is that the JDK provides a *subset* of the
javax.transaction classes that the JTA specification defines. And that
creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
depending on which bundle is used to wire in the transaction packages.
The JVM transaction packages are exported via the system bundle (just
like any other JVM package). On Felix, the JVM packages are exported
with the version of the JVM you are running on (e.g. if you are
running Java 5, the version attribute is set to 1.5.0). Our JTA spec
bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
with version 1.1.0.
Now, openjpa has the following javax.transaction imports:
javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
On Felix, the container wires these imports using the system bundle
since the system bundle exports these packages with higher version
then the JTA bundle and that creates the NoClassDefFoundError
problems. So, one would think that updating the version in our JTA
spec bundle to something higher then 1.5 or 1.6 should work. And I
think that should work but it doesn't seem to be working right on
Felix. I don't know if this is a bug or if I'm just missing something
or doing things wrong. When I install the openjpa bundle for the first
time, its transaction imports get wired to our JTA bundle. But once I
restart Felix, the openjpa transaction imports are wired to the system
bundle.... maybe somebody knows what's going on here?
Interestingly enough, Equinox exposes the JVM packages with version
0.0.0 and so I don't run into these NoClassDefFoundError errors there.
One thing that worked for me reliably is when I updated the JTA spec
bundle to be a fragment bundle (attaching itself to the system
bundle). That way, the missing transaction classes can be loaded
through the system bundle classloader. So, I'm wondering if we should
turn the JTA spec bundle into a fragment bundle (just manifest
updates) to deal with this problem?
Jarek
Re: jta spec bundle issue in felix
Posted by Lin Sun <li...@gmail.com>.
Also, would it be possible to get it working by specify a version range, like:
Import-Package:javax.transaction;version=”[1.1,1.2)”
Lin
On Wed, Jun 10, 2009 at 4:06 PM, Lin Sun<li...@gmail.com> wrote:
> Interesting prob... I wonder if you add the split-package (see
> http://www.aqute.biz/Code/Bnd) when you export the jta packages would
> solve the prob for you. This is what I have been using but I only
> tried Equinox so far.
>
> Export-Package = \
> javax.transaction;version=1.1;-split-package:=first, \
> javax.transaction.xa;version=1.1;-split-package:=first
>
> Lin
>
> On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gawor<jg...@gmail.com> wrote:
>> Hey all,
>>
>> I'm experimenting with JPA (OpenJPA specifically) in osgi environment
>> and I ran into an interesting issue with the transaction API. The root
>> of the problem is that the JDK provides a *subset* of the
>> javax.transaction classes that the JTA specification defines. And that
>> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
>> depending on which bundle is used to wire in the transaction packages.
>>
>> The JVM transaction packages are exported via the system bundle (just
>> like any other JVM package). On Felix, the JVM packages are exported
>> with the version of the JVM you are running on (e.g. if you are
>> running Java 5, the version attribute is set to 1.5.0). Our JTA spec
>> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
>> with version 1.1.0.
>>
>> Now, openjpa has the following javax.transaction imports:
>> javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
>> On Felix, the container wires these imports using the system bundle
>> since the system bundle exports these packages with higher version
>> then the JTA bundle and that creates the NoClassDefFoundError
>> problems. So, one would think that updating the version in our JTA
>> spec bundle to something higher then 1.5 or 1.6 should work. And I
>> think that should work but it doesn't seem to be working right on
>> Felix. I don't know if this is a bug or if I'm just missing something
>> or doing things wrong. When I install the openjpa bundle for the first
>> time, its transaction imports get wired to our JTA bundle. But once I
>> restart Felix, the openjpa transaction imports are wired to the system
>> bundle.... maybe somebody knows what's going on here?
>>
>> Interestingly enough, Equinox exposes the JVM packages with version
>> 0.0.0 and so I don't run into these NoClassDefFoundError errors there.
>>
>> One thing that worked for me reliably is when I updated the JTA spec
>> bundle to be a fragment bundle (attaching itself to the system
>> bundle). That way, the missing transaction classes can be loaded
>> through the system bundle classloader. So, I'm wondering if we should
>> turn the JTA spec bundle into a fragment bundle (just manifest
>> updates) to deal with this problem?
>>
>> Jarek
>>
>
Re: jta spec bundle issue in felix
Posted by Lin Sun <li...@gmail.com>.
Interesting prob... I wonder if you add the split-package (see
http://www.aqute.biz/Code/Bnd) when you export the jta packages would
solve the prob for you. This is what I have been using but I only
tried Equinox so far.
Export-Package = \
javax.transaction;version=1.1;-split-package:=first, \
javax.transaction.xa;version=1.1;-split-package:=first
Lin
On Wed, Jun 10, 2009 at 1:58 PM, Jarek Gawor<jg...@gmail.com> wrote:
> Hey all,
>
> I'm experimenting with JPA (OpenJPA specifically) in osgi environment
> and I ran into an interesting issue with the transaction API. The root
> of the problem is that the JDK provides a *subset* of the
> javax.transaction classes that the JTA specification defines. And that
> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
> depending on which bundle is used to wire in the transaction packages.
>
> The JVM transaction packages are exported via the system bundle (just
> like any other JVM package). On Felix, the JVM packages are exported
> with the version of the JVM you are running on (e.g. if you are
> running Java 5, the version attribute is set to 1.5.0). Our JTA spec
> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
> with version 1.1.0.
>
> Now, openjpa has the following javax.transaction imports:
> javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
> On Felix, the container wires these imports using the system bundle
> since the system bundle exports these packages with higher version
> then the JTA bundle and that creates the NoClassDefFoundError
> problems. So, one would think that updating the version in our JTA
> spec bundle to something higher then 1.5 or 1.6 should work. And I
> think that should work but it doesn't seem to be working right on
> Felix. I don't know if this is a bug or if I'm just missing something
> or doing things wrong. When I install the openjpa bundle for the first
> time, its transaction imports get wired to our JTA bundle. But once I
> restart Felix, the openjpa transaction imports are wired to the system
> bundle.... maybe somebody knows what's going on here?
>
> Interestingly enough, Equinox exposes the JVM packages with version
> 0.0.0 and so I don't run into these NoClassDefFoundError errors there.
>
> One thing that worked for me reliably is when I updated the JTA spec
> bundle to be a fragment bundle (attaching itself to the system
> bundle). That way, the missing transaction classes can be loaded
> through the system bundle classloader. So, I'm wondering if we should
> turn the JTA spec bundle into a fragment bundle (just manifest
> updates) to deal with this problem?
>
> Jarek
>
Re: jta spec bundle issue in felix
Posted by David Jencks <da...@yahoo.com>.
First of all I think we should lean on felix to provide a 1.0 package
version for their tx classes.
Second without the split-bundle lin suggests wont' there be this
problem anyway since the system bundle will have used up the packages
and ours will be ignored?
thanks
david jencks
On Jun 10, 2009, at 10:58 AM, Jarek Gawor wrote:
> Hey all,
>
> I'm experimenting with JPA (OpenJPA specifically) in osgi environment
> and I ran into an interesting issue with the transaction API. The root
> of the problem is that the JDK provides a *subset* of the
> javax.transaction classes that the JTA specification defines. And that
> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
> depending on which bundle is used to wire in the transaction packages.
>
> The JVM transaction packages are exported via the system bundle (just
> like any other JVM package). On Felix, the JVM packages are exported
> with the version of the JVM you are running on (e.g. if you are
> running Java 5, the version attribute is set to 1.5.0). Our JTA spec
> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
> with version 1.1.0.
>
> Now, openjpa has the following javax.transaction imports:
> javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
> On Felix, the container wires these imports using the system bundle
> since the system bundle exports these packages with higher version
> then the JTA bundle and that creates the NoClassDefFoundError
> problems. So, one would think that updating the version in our JTA
> spec bundle to something higher then 1.5 or 1.6 should work. And I
> think that should work but it doesn't seem to be working right on
> Felix. I don't know if this is a bug or if I'm just missing something
> or doing things wrong. When I install the openjpa bundle for the first
> time, its transaction imports get wired to our JTA bundle. But once I
> restart Felix, the openjpa transaction imports are wired to the system
> bundle.... maybe somebody knows what's going on here?
>
> Interestingly enough, Equinox exposes the JVM packages with version
> 0.0.0 and so I don't run into these NoClassDefFoundError errors there.
>
> One thing that worked for me reliably is when I updated the JTA spec
> bundle to be a fragment bundle (attaching itself to the system
> bundle). That way, the missing transaction classes can be loaded
> through the system bundle classloader. So, I'm wondering if we should
> turn the JTA spec bundle into a fragment bundle (just manifest
> updates) to deal with this problem?
>
> Jarek
Re: jta spec bundle issue in felix
Posted by Guillaume Nodet <gn...@gmail.com>.
Btw, not sure how you deployed the tx manager (if you did so), but
there is an osgi bundle that i wrote to do that:
http://svn.apache.org/repos/asf/felix/trunk/transaction/
On Thu, Jun 11, 2009 at 17:03, Guillaume Nodet<gn...@gmail.com> wrote:
> FWIW, Karaf solved the problem was explicitely removing the
> javax.transaction package exported by the system bundle and deploying
> the geronimo jta jar.
>
> On Wed, Jun 10, 2009 at 19:58, Jarek Gawor<jg...@gmail.com> wrote:
>> Hey all,
>>
>> I'm experimenting with JPA (OpenJPA specifically) in osgi environment
>> and I ran into an interesting issue with the transaction API. The root
>> of the problem is that the JDK provides a *subset* of the
>> javax.transaction classes that the JTA specification defines. And that
>> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
>> depending on which bundle is used to wire in the transaction packages.
>>
>> The JVM transaction packages are exported via the system bundle (just
>> like any other JVM package). On Felix, the JVM packages are exported
>> with the version of the JVM you are running on (e.g. if you are
>> running Java 5, the version attribute is set to 1.5.0). Our JTA spec
>> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
>> with version 1.1.0.
>>
>> Now, openjpa has the following javax.transaction imports:
>> javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
>> On Felix, the container wires these imports using the system bundle
>> since the system bundle exports these packages with higher version
>> then the JTA bundle and that creates the NoClassDefFoundError
>> problems. So, one would think that updating the version in our JTA
>> spec bundle to something higher then 1.5 or 1.6 should work. And I
>> think that should work but it doesn't seem to be working right on
>> Felix. I don't know if this is a bug or if I'm just missing something
>> or doing things wrong. When I install the openjpa bundle for the first
>> time, its transaction imports get wired to our JTA bundle. But once I
>> restart Felix, the openjpa transaction imports are wired to the system
>> bundle.... maybe somebody knows what's going on here?
>>
>> Interestingly enough, Equinox exposes the JVM packages with version
>> 0.0.0 and so I don't run into these NoClassDefFoundError errors there.
>>
>> One thing that worked for me reliably is when I updated the JTA spec
>> bundle to be a fragment bundle (attaching itself to the system
>> bundle). That way, the missing transaction classes can be loaded
>> through the system bundle classloader. So, I'm wondering if we should
>> turn the JTA spec bundle into a fragment bundle (just manifest
>> updates) to deal with this problem?
>>
>> Jarek
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: jta spec bundle issue in felix
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, Karaf solved the problem was explicitely removing the
javax.transaction package exported by the system bundle and deploying
the geronimo jta jar.
On Wed, Jun 10, 2009 at 19:58, Jarek Gawor<jg...@gmail.com> wrote:
> Hey all,
>
> I'm experimenting with JPA (OpenJPA specifically) in osgi environment
> and I ran into an interesting issue with the transaction API. The root
> of the problem is that the JDK provides a *subset* of the
> javax.transaction classes that the JTA specification defines. And that
> creates problems (i.e. java.lang.NoClassDefFoundError) at runtime
> depending on which bundle is used to wire in the transaction packages.
>
> The JVM transaction packages are exported via the system bundle (just
> like any other JVM package). On Felix, the JVM packages are exported
> with the version of the JVM you are running on (e.g. if you are
> running Java 5, the version attribute is set to 1.5.0). Our JTA spec
> bundle (geronimo-jta_1.1_spec-1.1.1.jar) exports the transaction API
> with version 1.1.0.
>
> Now, openjpa has the following javax.transaction imports:
> javax.transaction;version="1.1", javax.transaction.xa;version="1.1".
> On Felix, the container wires these imports using the system bundle
> since the system bundle exports these packages with higher version
> then the JTA bundle and that creates the NoClassDefFoundError
> problems. So, one would think that updating the version in our JTA
> spec bundle to something higher then 1.5 or 1.6 should work. And I
> think that should work but it doesn't seem to be working right on
> Felix. I don't know if this is a bug or if I'm just missing something
> or doing things wrong. When I install the openjpa bundle for the first
> time, its transaction imports get wired to our JTA bundle. But once I
> restart Felix, the openjpa transaction imports are wired to the system
> bundle.... maybe somebody knows what's going on here?
>
> Interestingly enough, Equinox exposes the JVM packages with version
> 0.0.0 and so I don't run into these NoClassDefFoundError errors there.
>
> One thing that worked for me reliably is when I updated the JTA spec
> bundle to be a fragment bundle (attaching itself to the system
> bundle). That way, the missing transaction classes can be loaded
> through the system bundle classloader. So, I'm wondering if we should
> turn the JTA spec bundle into a fragment bundle (just manifest
> updates) to deal with this problem?
>
> Jarek
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com