Thanks, Steve, for the reply. As I continue to experiment in this area,
I'm coming to the same conclusion... But, I can understand what these API
providers are trying to do... Since you normally want to isolate the
API's from the implementation, you would want to package the API's in it's
own bundle. So, from a Glassfish perspective, each of the API jar files
along with the RI implementation files need to be separate bundles. It's
just when these API's and RI's are attempted to be used in alternate OSGi
environments that we hit these issues.
If these API jar files are "clean" with no bundle activators, then they
wouldn't work in Glassfish. And, there wouldn't be an example of what's
required for OSGi, which can be handy for newbies.
I suppose the best alternative is to have both types of API jar files.
Have an OSGi-enabled API bundle along with a clean API jar file. This
shouldn't be too much to ask, especially since this OSGi activator
requirement only hits the API jar files that contain implementation code
-- JPA, Bean Validation, and JSON-P that I am aware of. Maybe this is
just another item to add to our Java EE 8 wish list to have consistent
deliverables from all JSR expert group teams.
-- Kevin
From: Steve Ebersole <steve.ebersole_at_redhat.com>
To: jsr338-experts_at_jpa-spec.java.net,
Date: 12/17/2013 02:07 PM
Subject: [jsr338-experts] Re: API bundles and OSGi bundle
activators
Seems incorrect to have jpa-api jars register bundle activators for
specific providers. At least thats what I assume you are doing. The
bundle activator really ought to be defined within the provider bundles.
Forcing people to use particular providers merely through the inclusion of
one jpa-api jar or another just feels wrong, even if JPA and EE (and
Enterprise OSGi) do not explicitly disallow it. Now what happens when an
OSGi bundle has access to the jpa-api jar from Hibernate and Eclipse Link
and Geronimo and ... ? Thats just an ugly scenario since some of these
jpa-api jars are defining bundle activators.
To your specific question, the various containers should work in portable
manners but in practice they really often do not. Our experience in
getting Hibernate working with OSGi is that these containers often have
inconsistent expectations. Even more of a reason for the jpa-api jars to
be "clean" imo.
On 11/15/2013 10:27 AM, Kevin Sutter wrote:
Hi,
When we attempt to use the JPA API jar file (
https://wikis.oracle.com/display/GlassFish/Java+EE+7+Maven+Coordinates) in
WebSphere, the OSGi bundle activator doesn't seem to work properly. The
WebSphere OSGi runtime is based on Apache Aries. If we use the JPA API
jar file that the Geronimo team created (
http://search.maven.org/remotecontent?filepath=org/apache/geronimo/specs/geronimo-jpa_2.0_spec/1.1/geronimo-jpa_2.0_spec-1.1.jar
) [1], that bundle activator seems to work just fine. I'm not an expert
with these OSGi bundle activators and I'm following up on various avenues.
But, since I ran into this issue first with our JPA API jar file, I
thought I would post this out to our expert group first.
So, my question is whether the bundle activators provided by our API jar
files are supposed to be generic enough to work with any OSGi provider? I
notice on the EclipseLink site that we have tested this with the Gemini
environment and possibly the Equinox environment? So, I'm sure they work
fine with WebLogic and Glassfish.
I guess I'm wondering what the expected pattern is. Are these provided
bundle activators just provided as an example? And, we as consumers are
expected to override these bundle activators to work with our specific
environments?
FYI, I hit this issue with our JPA API bundle, but it looks like other
Java EE API jar files are in the same boat.
Thanks,
Kevin Sutter
[1] I have noticed that the JPA 2.1 API jar file created by Geronimo
currently doesn't contain any bundle activators, so I provided a link to
the JPA 2.0 version of the API jar file.