Community
Participate
Working Groups
EclipseLink 2.2 depends on the javax.persistence package to be installed, with ;jpa="2.0". (However, javax.persistence.2.0.3 exports the package version as 2.0.3 rather than 1.1) This causes problems when using Virgo, since it ships a version in com.springsource.javax.persistence which is just the wrapped API, and which does not export the jpa=2.0 attribute. It's not clear to me why the javax.persistence bundle shouldn't be just the API, and that if there are any EclipseLink specific code that needs to be imported by others, why it shouldn't be in an org.eclipse.eclipselink.javax.persistence bundle instead. What is the purpose of the Activator in the javax.persistence package? What if it's exported from (say) a containing OSGi server like WebSphere?
A few comments: The jpa="2.0" attribute is specified as the way to find the JPA apis in the OSGi JPA specification. As implementations start to follow the specification, I suspect most javax.persistence implementations will include that attribute. We export vestion 2.0.3 because we started shipping javax.persistence classes before the specification described the version as 1.1. For backwards compatibility, we cannot reduce the version since we already have a 2.0 version available and would not want that version picked up instead of our latest. Some of the implementation classes are required by the JPA specification. (e.g. Persistence, PersistenceProviderResolverHolder) The activator will work with EclispeLink JPA used in either of our two OSGi-compliant implementations (our legacy implementation and the spec-based Eclipse Gemini implementation). We have not done any testing on an OSGi-Only application server without one of those two implementations available. Are you actually seeing problems on WebSphere? (The activator just sets the provider resolver which should not be an issue on a JEE server)
The problem is that Virgo, which I have tried and found problems on, exports javax.persistence *without* the jpa attribute. Furthermore, the OSGi enterprise spec (downloaded from http://repo1.maven.org/maven2/org/osgi/org.osgi.enterprise/4.2.0/org.osgi.enterprise-4.2.0.jar) doesn't specify the JPA attribute: Import-Package: javax.management.openmbean;resolution:=optional,javax. naming;resolution:=optional,javax.naming.directory;resolution:=option al,javax.persistence;resolution:=optional,... As a result if you install both javax.persistence and org.osgi.enterprise_4.2.0 into Virgo, depending on the installation order it either pulls the com.springsource.javax.persistence bundle out or the javax.persistence bundle. If you bind to the com.springsource.javax.persistence package, then EclipseLink JPA fails to work, since it seems to depend specifically on the javax.persistence bundle as exported by the EclipseLink version. Even without the attribute, the fact that the javax.persistence contains an EclipseLink specific activator means that even if SpringSource started to include that attribute, EclipseLink may not work. Consider what would happen if I packaged javax.persistence with a jpa=2.0 attribute. This would bind as far as the API itself is concerned, but the activator (bundled in the EclipseLink specific package) wouldn't be present. So, if as you say, SpringSource put jpa=2.0 on their package, it still causes a problem if other EclipseLink APIs depend specifically on the javax.persistence bundle as provided by EclipseLink, if you're using Import-Package to loosely bind to it.
What if you don't install the eclipselink javax.persistence bundle?
Then it fails, because the eclipselink.JPA packages import ;jpa="2.0" which the com.springsource.javax.persistence doesn't export.
Is removing the com.springsource.javax.persistence bundle from virgo an option?
You'd have to ask the Virgo guys about that, but given that they use it for their JPA setup I suspect they might not want to. The bundle is really doing two things; providing the API and registering the activator. If the two concerns were split out, then this might not be (as much of) an issue, since then the com.springsource one could be the definitive provider of the javax.persistence API. Of course, that might have to export the jpa=2.0 eventually in order to work.
(In reply to comment #0) ... > It's not clear to me why the javax.persistence bundle shouldn't be just the > API, and that if there are any EclipseLink specific code that needs to be > imported by others, why it shouldn't be in an > org.eclipse.eclipselink.javax.persistence bundle instead. What is the purpose > of the Activator in the javax.persistence package? What if it's exported from > (say) a containing OSGi server like WebSphere? The problem is that the JPA API jar is not just an API, it contains a resolver: the persistence unit location functionality. In Java SE the default implementation scans the classpath for META-INF/persistence.xml files. This doesn't work well in OSGi ;-) so in JPA 2.0, the "resolver" was made pluggable and service-oriented based on the experience of EclipseLink in OSGi. The resolver that EclipseLink OSGi (and it's successor Gemini JPA) provides can support multiple concurrent JPA providers as it is based on service interfaces defined in the OSGi Enterprise spec. So using the EclipseLink provided javax.persistence bundle is the right thing to do in OSGi. The bundle provided by SpringSource is not built for OSGi but for Spring DM apps that have their classpaths flattened. The fact that Virgo supports both Java SE style and OSGi style applications means that to run both concurrently you'd need two javax.persistence implementations: one with the classpath scanning resolver and one with the OSGi resolver. Virgo has some sophisticated classpath management infrastructure so I assume this is something they could support and expose usage of via application configurations? I'm going to re-target this to Virgo to continue the investigation/conversation.
This is not a Virgo bug, it is an EclipseLink design issue. The fact that it was noticed by installation into Virgo does not make it Virgo specific. The issues with the current implementation are: * Although packages may exist, the version number of the javax.persistence package is supposed to be 1.1 according to the Enterprise OSGi spec. It is not in this case. * The EclipseLink JPA implementation has a tight binding to the EclipseLink javax.persistence classes. It does not work if this is substituted for another OSGi bundle exporting the javax.persistence packages. * It is not possible to have a enterprise Java OSGi 'bootstrap' process using an externally acquired javax.persistence package, such as might be the case if exposed via the bootclasspath. None of these issues are related to Virgo. This will cause the same problem if using e.g. bundles built for Aries JPA, since the examples often use Import-Package: javax.persistence;version="[1.2,2.0)";jpa="2.0" which will fail to find this package. Whilst you are correct that the javax.persistence package needs to have an OSGi resolver, it is not the case that it needs to be delivered in the same bundle as the javax.persistence bundle itself. The API can be delivered in one bundle and the OSGi publisher/announcer can be delivered in another bundle. I suggest to resolve this issue, instead of continuing down the javax.persistence_2.x stream, we create a couple of bundles: org.eclipse.jpa.javax.persistence 1.1 (containing the javax.persistence packages only) org.eclipse.jpa.provider (which registers the OSGi services necessary). Note that the javax.persistence is in violation of the examples in the OSGi enterprise specification; in Table 127.1 it suggests that the provider implementation range must use [1.1,1.2) and that clients use [1.1,2.0). If there is no interest in fixing this in EclipseLink, then it should be closed WONTFIX rather than reassigning to projects which are not responsible for this issue.
(It's also worth noting that Virgo does run JPA applications under OSGi, and that the com.springsource is a valid OSGi bundle. The 'greenpages' sample shows this in action.)
(In reply to comment #8) > This is not a Virgo bug, it is an EclipseLink design issue. The fact that it > was noticed by installation into Virgo does not make it Virgo specific. > > The issues with the current implementation are: > > * Although packages may exist, the version number of the javax.persistence > package is supposed to be 1.1 according to the Enterprise OSGi spec. It is not > in this case. Correct EclipseLink, for backward compatibility issues has a version number of 2. > * The EclipseLink JPA implementation has a tight binding to the EclipseLink > javax.persistence classes. It does not work if this is substituted for another > OSGi bundle exporting the javax.persistence packages. Yes, as the functionality we're discussing predates the OSGi spec the implementation is indeed tightly coupled to EclipseLink JPA. OSGi spec compliant work is going on in Gemini JPA. > * It is not possible to have a enterprise Java OSGi 'bootstrap' process using > an externally acquired javax.persistence package, such as might be the case if > exposed via the bootclasspath. Please see my previous comment on why it is necessary to have an OSGi-aware implementation of javax.persistence. > > None of these issues are related to Virgo. This will cause the same problem if > using e.g. bundles built for Aries JPA, since the examples often use > Import-Package: javax.persistence;version="[1.2,2.0)";jpa="2.0" which will fail > to find this package. I just checked out the trunk of Aries and the JPA Container pom sets up the dependencies with the same top range limit as EclipseLink JPA. EclipseLink also adds jpa="2.0". It looks like we're on a similar page. The Aries example you pointed at previously may just need updating? Aries: ------ <Import-Package> javax.persistence;version="[1.0.0,2.1.0)", javax.persistence.spi;version="[1.0.0,2.1.0)", javax.persistence.criteria;version="[1.1.0,2.1.0)";resolution:=optional, javax.persistence.metamodel;version="[1.1.0,2.1.0)";resolution:=optional, ... EclipseLink: ------------ Import-Package: javax.persistence;jpa="2.0";version="[1.1.0,2.1)",java x.persistence.criteria;jpa="2.0";version="[1.1.0,2.1)",javax.persiste nce.metamodel;jpa="2.0";version="[1.1.0,2.1)",javax.persistence.spi;j pa="2.0";version="[1.1.0,2.1)" > Whilst you are correct that the javax.persistence package needs to have an OSGi > resolver, it is not the case that it needs to be delivered in the same bundle > as the javax.persistence bundle itself. The API can be delivered in one bundle > and the OSGi publisher/announcer can be delivered in another bundle. We definitely debated this but came to the conclusion that this configuration was open to a number of timing issues. This is something we can certainly discuss. > I suggest to resolve this issue, instead of continuing down the > javax.persistence_2.x stream, we create a couple of bundles: > org.eclipse.jpa.javax.persistence 1.1 (containing the javax.persistence > packages only) > org.eclipse.jpa.provider (which registers the OSGi services necessary). As I said, we considered this and come to the configuration we currently have. We'd definitely be open to accepting help to work through the possible deployment scenarios to ensure that things work as expected. Timing is everything after all. > Note that the javax.persistence is in violation of the examples in the OSGi > enterprise specification; in Table 127.1 it suggests that the provider > implementation range must use [1.1,1.2) and that clients use [1.1,2.0). Yup. Backwards compatibility is a pain. However the spec is clear that "All JPA Packages *must* also have an attribute called jpa that specifies the JPA version" (emphasis mine). We are spec compliant in this regard as it is the only thing one can truly rely on. > If there is no interest in fixing this in EclipseLink, then it should be closed > WONTFIX rather than reassigning to projects which are not responsible for this > issue. I'm definitely open to reopening the version range issue too. So far we've been focusing on backwards compatibility--which is the Eclipse way. But there are always arguments for breaking backwards compatibility. The OSGi enterprise specification coming out after JPA 2.0 and the conflict between JSR version numbers and OSGi numbering is the issue here. EclipseLink 2.0 shipped in December of 2009 and the OSGi enterprise spec shipped in March of 2010. If I had a time machine I'd definitely go back and ship EclipseLink with an OSGi spec compliant version range. ;-) But in terms of Virgo I think there is a problem for them here. I think the issue is the osgi.enterprise bundle they deploy with their SpringSource javax.persistence bundle. osgi.enterprise doesn't import a specific version of JPA and I would think that at framework startup time the osgi.enterprise bundle would resolve to the SpringSource JPA 1.0 javax.persistence bundle and that subsequent attempts to deploy OSGi Enterprise JPA 2.0 applications will never resolve. I think that regardless of what we do in EclipseLink or Gemini JPA, Virgo will not be able to get around this--it's very similar to the problem EE containers are facing with supporting JPA 1.0 and 2.0. Once the version is resolved to the osgi.enterprise bundle the other version will be unusable by JPA providers that also resolve against osgi.enterprise. However, if Virgo did not deploy the SpringSource javax.persistence bundle users would at least be able to choose between JPA 1.0 and 2.0. I've never used Virgo so I'm just theorizing here. Perhaps someone with Virgo knowledge could explain how to simultaneously deploy 1.0 and 2.0 applications.
(In reply to comment #9) > (It's also worth noting that Virgo does run JPA applications under OSGi, and > that the com.springsource is a valid OSGi bundle. The 'greenpages' sample shows > this in action.) Not sure how that's happening in "pure" OSGi given the classpath scanning I described previously and the need for JPA providers to have access to Entity classes. Prior to our work on EclipseLink OSGi most people used buddy classloading or the Virgo approach of classpath flattening to work around the strictness of OSGi. Are you sure the greenpages example is not a Virgo application rather than simply an OSGi application.
I've opened bug 337922 to track the version range issue which is independent of whether or not the OSGi JPA persistence provider resolver is included in javax.persistence or not.
(In reply to comment #10) On further thought, Alex, can you explain why you think the EclipseLink OSGi provider resolver is an issue? It's compatible with any OSGi Enterprise Spec complaint JPA provider. The SpringSource javax.persistence bundle Virgo includes is not OSGi Enterprise spec compliant and will scan it's bundle classpath for both persistence.xml and JPA providers--and find nothing. The only context in which this bundle could be useful would be in Java SE or in a Virgo Application with a flattened classloader.
It's not so much the resolver is an issue, but rather it tightly binds the eclipselink.jpa packages to use javax.persistence. At the moment, the eclipselink.jpa packages use Import-Package, which means they can bind to another provider which doesn't have this activator in place. In other words, it's a fragile dependency. It would be better to have a 'pure' API, which just contained the javax.persistence packages, and an OSGi JPA Provider which could bind to that package. To use EclipseLink, you'd need to have both the API and a JPA provider, but the latter could be deployed in a scenario where the javax.persistence is provided by someone else (e.g. from the bootclasspath). And yes, Virgo runs OSGi applications, not flattened classloaders. Though in the case of the Greenpages sample, the JPA hooks are wired with SpringDM. So it is OSGi apps, but not using the OSGi Enterprise JPA provider discovery mechanism.
(In reply to comment #14) > It's not so much the resolver is an issue, but rather it tightly binds the > eclipselink.jpa packages to use javax.persistence. At the moment, the > eclipselink.jpa packages use Import-Package, which means they can bind to > another provider which doesn't have this activator in place. In other words, > it's a fragile dependency. The o.e.p.jpa and javax.persistence bundles resolve via package import ranges and jpa="2.0" property. EclipseLink should work happily with another OSGi compliant javax.persistence bundle. The more we discuss this the more I'm convinced we have it right. We need an OSGi Enterprise compatible javax.persistence bundle that will find EMF and EMFBuilder services we publish and make them available through the "static" API, but it doesn't have to be EclipseLink's javax.persistence bundle. The problem you're facing is that Virgo is shipping a non-compliant bundle. > And yes, Virgo runs OSGi applications, not flattened classloaders. Though in > the case of the Greenpages sample, the JPA hooks are wired with SpringDM. So it > is OSGi apps, but not using the OSGi Enterprise JPA provider discovery > mechanism. As per my comment above, until they deploy an OSGi Enterprise compatible javax.persistence bundle you'll have to go along with how Virgo wants you to do JPA vs. what the spec says. This is why I reassigned this bug to Virgo. They have an issue and I don't think we do. But in all fairness they've never claimed to provide compliant JPA support.
(In reply to comment #15) > (In reply to comment #14) > > The problem you're facing is that Virgo is shipping a non-compliant bundle. Well, technically they're shipping a JPA compliant bundle, but not OSGi Enterprise JPA compliant. > > And yes, Virgo runs OSGi applications, not flattened classloaders. Though in > > the case of the Greenpages sample, the JPA hooks are wired with SpringDM. So it > > is OSGi apps, but not using the OSGi Enterprise JPA provider discovery > > mechanism. > > As per my comment above, until they deploy an OSGi Enterprise compatible > javax.persistence bundle you'll have to go along with how Virgo wants you to do > JPA vs. what the spec says. That's not strictly true; as I raised on another bug with Virgo, there is a workaround in that you can create a plan and install your bundle ahead of anything that needs it (like osgi.enterprise). Then the automatic resolution of JPA imporst won't kick in, because there's already the javax.persistence OSGi bundle installed. In light of the other bug (the version numbering issue) might I suggest that a way forwards will be to rename the bundle to something like org.eclipse.eclipselink.javax.persistence in order to drop the version number back down to the [1.1,2.0) range? I also think having 'eclipselink' as part of the name will highlight the fact that the package doesn't just contain javax.persistence API (as many other packages, like javax.servlet convey) but rather that it has {eclipselink|osgi} support built in? I will file another bug against Virgo to see if they can include an OSGi compliant version of JPA rather, with the jpa package export and JPA provider. We'll then be able to close this bug as invalid. Sound reasonable?
A quick comment. Our javax.persistence bundles ships not only as part of our OSGi disto, but also as part of our JEE distro. Addressing this issue will not be as simple as renaming the bundle.
I would be interested in whether adding the EclipseLink javax.persistence bundle to Virgo's repository/ext directory will solve this problem. Here's my analysis... Virgo includes the bundle com.springsource.javax.persistence-1.0.0.jar in its repository so that Tomcat's Catalina bundle can resolve and when the Spring framework bundles are resolved, the optional imports are wired rather than being discarded. This then opens the possibility for applications to use javax.persistence together with Spring. Note that the bundle com.springsource.javax.persistence-1.0.0.jar simply exports two standard "interface" packages javax.persistence and javax.persistence.spi both at version 1.0.0 and AFAIK does not have any behaviour (i.e. executable code). So Virgo should be equally happy to have the bundle replaced in repository/ext with another suitable bundle exporting those packages with suitable versions. The dependencies on those packages that are in place once Virgo has started "out of the box" are as follows. 1. Bundle com.springsource.org.apache.catalina.springsource version 6.0.29.S2-r1559 imports the package javax.persistence with a version range of [1.0.0, 2.0.0) and no other matching attributes. 2. Bundles org.springframework.context and org.springframework.orm (both at version 3.0.0.RELEASE) optionally import the packages javax.persistence and javax.persistence.spi both with a version range of [1.0.0, 3.0.0) and no other matching attributes. It seems the the EclipseLink javax.persistence bundle will not satisfy the Catalina dependency, although it would appear to satisfy the optional dependencies of Spring framework. I'm not sure what the ramifications of Catalina being wired to a distinct export of javax.persistence, but I guess this won't cause any trouble provided the web and persistence layers of applications are cleanly separated. But it does seem that Catalina will need com.springsource.javax.persistence-1.0.0.jar to be present in addition to any EclipseLink javax.persistence bundle. If both are present and IIRC, then Spring framework should wire to Eclipselink for javax.persistence/.spi because these have a higher package version than those exported by com.springsource.javax.persistence-1.0.0.jar.
BTW I don't understand what is meant by "flattened classloader". That's certainly not a Virgo term. I point this out for any observers who may also be confused.
(In reply to comment #18) > I would be interested in whether adding the EclipseLink javax.persistence > bundle to Virgo's repository/ext directory will solve this problem. Replace, yes. Add, no. (That's what I did.) > The dependencies on those packages that are in place once Virgo has started > "out of the box" are as follows. > > 1. Bundle com.springsource.org.apache.catalina.springsource version > 6.0.29.S2-r1559 imports the package javax.persistence with a version range of > [1.0.0, 2.0.0) and no other matching attributes. > > 2. Bundles org.springframework.context and org.springframework.orm (both at > version 3.0.0.RELEASE) optionally import the packages javax.persistence and > javax.persistence.spi both with a version range of [1.0.0, 3.0.0) and no other > matching attributes. > > It seems the the EclipseLink javax.persistence bundle will not satisfy the > Catalina dependency, although it would appear to satisfy the optional > dependencies of Spring framework. I'm not sure what the ramifications of > Catalina being wired to a distinct export of javax.persistence, but I guess > this won't cause any trouble provided the web and persistence layers of > applications are cleanly separated. The OSGi enterprise bundle from maven does not have a versioned dependency, nor a JPA attribute. So it could wire to the com.springsource one instead causing clients to be unresolved. If the version was fixed (I.e. made 1.1) then a straight replacement would work for both instances. > But it does seem that Catalina will need > com.springsource.javax.persistence-1.0.0.jar to be present in addition to any > EclipseLink javax.persistence bundle. If both are present and IIRC, then Spring > framework should wire to Eclipselink for javax.persistence/.spi because these > have a higher package version than those exported by > com.springsource.javax.persistence-1.0.0.jar.
(In reply to comment #20) > (In reply to comment #18) > > I would be interested in whether adding the EclipseLink javax.persistence > > bundle to Virgo's repository/ext directory will solve this problem. > > Replace, yes. Add, no. (That's what I did.) If everything appears to work when you replace the bundle, then I'm intrigued to know where the Tomcat Catalina bundle is wired to for javax.persistence. You can see this by issuing: osgi>packages javax.persistence in an Equinox console (configured via the user region properties file in Virgo 2.1.0 and in kernel launch properties in lib in Virgo 3.0.0.M01).
I used a plan to install the javax.persistence prior to the ogsi.enterprise, so when the osgi.enterprise was installed it bound to the javax.persistence. If I installed then in the other order, the installation of osgi.enterprise would cause the com.springsource to be installed from the repository, such that my bundles worked as expected. As you surmise, the catalina is bound to the older one: osgi> packages javax.persistence javax.persistence; version="2.0.3"<javax.persistence_2.0.3.v201010191057 [66]> org.eclipse.persistence.core_2.2.0.v20110202-r8913 [69] imports org.eclipse.persistence.jpa_2.2.0.v20110202-r8913 [70] imports org.springframework.context_3.0.0.RELEASE [75] imports org.springframework.orm_3.0.0.RELEASE [79] imports osgi.enterprise_4.2.0.201003190513 [112] imports org.eclipse.persistence.core_2.2.0.v20110202-r8913 [115] imports org.eclipse.persistence.jpa_2.2.0.v20110202-r8913 [116] imports org.eclipse.gemini.jpa_1.0.0.M4-incubation [119] imports com.my.example.par-SNAPSHOT-com.my.bundle.jpa-SNAPSHOT [123] imports javax.persistence; version="1.0.0"<com.springsource.javax.persistence_1.0.0 [89] > com.springsource.org.apache.catalina.springsource_6.0.29.S2-r1559 [91] imports javax.persistence; version="2.0.3"<javax.persistence_2.0.3.v201010191057 [111]>
(In reply to comment #22) Ok, thanks. Then that seems a reasonable solution to this bug. At least from a Virgo perspective I think it's the best we can achieve. (Note the duplicate bundle 111, which is a copy of bundle 66. We need to avoid this happening as it's a waste of resources and could also cause confusion. It's a side-effect of the framework being configured to allow more than one bundle with the same BSN and version. We should probably address that in a separate bug to avoid mass confusion here.)
Disclaimer: My knowledge of Virgo is based on very old information dating back to the launch of Spring DM and not having ever used Spring DM or Virgo I could be entirely out to lunch. :) (In reply to comment #19) > BTW I don't understand what is meant by "flattened classloader". That's > certainly not a Virgo term. I point this out for any observers who may also be > confused. I was referring to the classloader sharing that I believe is done between bundles in an application. Rather than the usually bundle classloader hierarchy I was under the impression that Virgo "flattens" the hierarchy and that all bundles in an app share the classloader. This is how I understand non-OSGi frameworks were made usable as an alternative to buddy loading?
(In reply to comment #18) > Note that the bundle com.springsource.javax.persistence-1.0.0.jar simply > exports two standard "interface" packages javax.persistence and > javax.persistence.spi both at version 1.0.0 and AFAIK does not have any > behaviour (i.e. executable code). This is not the case. The com.springsource.javax.persistence-1.0.0 bundle contains the JPA 1.0 API jar which is not entirely interfaces. It does contain behavior. The OSGi problematic code is in javax.persistence.Persistence.findAllProviders which tries to load JPA provider service files and which in OSGi fails miserably. In JPA 2.0 the spec (and "API" jar) allowed for replacement of the provider resolver code to support looking up providers using alternate mechanisms like, for example, OSGi services as defined in the OSGi Enterprise Spec.
(In reply to comment #24) > Disclaimer: My knowledge of Virgo is based on very old information dating back > to the launch of Spring DM and not having ever used Spring DM or Virgo I could > be entirely out to lunch. :) I'm afraid you are indeed dining elsewhere. ;-) I think I'll blog about the Virgo approach and post a link here for posterity. I don't think we've adequately documented the approach, except in a patent application that is probably still going through. > > (In reply to comment #19) > > BTW I don't understand what is meant by "flattened classloader". That's > > certainly not a Virgo term. I point this out for any observers who may also be > > confused. > > I was referring to the classloader sharing that I believe is done between > bundles in an application. Rather than the usually bundle classloader > hierarchy I was under the impression that Virgo "flattens" the hierarchy and > that all bundles in an app share the classloader. This is how I understand > non-OSGi frameworks were made usable as an alternative to buddy loading?
(In reply to comment #25) > (In reply to comment #18) > > Note that the bundle com.springsource.javax.persistence-1.0.0.jar simply > > exports two standard "interface" packages javax.persistence and > > javax.persistence.spi both at version 1.0.0 and AFAIK does not have any > > behaviour (i.e. executable code). > > This is not the case. The com.springsource.javax.persistence-1.0.0 bundle > contains the JPA 1.0 API jar which is not entirely interfaces. It does contain > behavior. The OSGi problematic code is in > javax.persistence.Persistence.findAllProviders which tries to load JPA provider > service files and which in OSGi fails miserably. In JPA 2.0 the spec (and > "API" jar) allowed for replacement of the provider resolver code to support > looking up providers using alternate mechanisms like, for example, OSGi > services as defined in the OSGi Enterprise Spec. Ok, thanks. I'm sadder and wiser now.
(In reply to comment #26) > I think I'll blog about the Virgo approach and post a link here for posterity. http://underlap.blogspot.com/2011/02/thread-context-class-loading-in-virgo.html
I think we've made it clear that the javax.persistence bundle provided by EclipseLink doesn't contain any EclipseLink specific code--it does contain EclipseLink's implementation of a JPA 2.0 OSGi Enterprise compliant EMF and EMFB service resolver which should work with any compliant JPA provider. As such I'm going to close this bug as WONTFIX but please note that I have opened Bug 337922 to address the issue of exported version ranges.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
