Looking at the OSGi JPA Service Spec (4.2) and the two implementations,
Aries and Gemini, I somehow feel there's rather a mismatch, or maybe
it's just my misunderstanding, so I'd be glad if someone could comment
the following assumptions:
1) Aries' JPA container implements most of the JPA provider behaviour
defined in the OSGi enterprise spec in a central place. A given JPA
implementation (like OpenJPA or Eclipselink) just needs to register
their javax.persistence.spi.PersistenceProvider implementation in the
service registry and Aries will do all service and bundle tracking and
EntityManagerFactory registration on their behalf.
2) Despite the title "JPA Service Specification", the OSGi Enterprise
Spec does not really specify a JPA Service. The spec just mentions JPA
providers, persistence bundles, and client bundles, all in plural. The
spec also has no clear distinction between a Persistence Provider (i.e.
an implementation of JPA spec (JSR-317) that works in Java SE and EE but
has no OSGi support) and a JPA provider that adds OSGi support to a
vanilla Persistence Provider.
3) It is conceivable to implement a com.example.myjpa OSGi bundle which
complies with both JSR-317 and the OSGi JPA spec. This bundle would
track all persistence bundles and datasources and register
EntityManagerFactory services for the matching persistence units.
4) An all-in-one vanilla+OSGi persistence provider along the lines of 3)
would cause conflicts with Aries JPA, because Aries would try to
register EntityManagerFactory on behalf of the provider, whereas this
provider registers its own factories.
5) Is OSGi Enterprise Java EE or Java SE? Should EMFs be created using
PersistenceProvider.createContainerEntityManagerFactory() or
PersistenceProvider.createEntityManagerFactory()?
JSR-317 7.3.1 says:
"Within a Java EE environment, an entity manager factory may be injected
using the PersistenceUnit annotation or obtained through JNDI lookup."
So if OSGi is not Java SE, then it must be Java EE and thus support
@PersistenceUnit injection, which AFAIK is not currently possible in Aries.
The background for all this: I used Aries and OpenJPA for a
proof-of-concept OSGi+JPA implementation a while ago. Currently, I'm
experimenting with Gemini, and at first I thought that their design
looked rather broken compared to Aries, in tying their OSGi JPA provider
to Eclipselink, which is really an example of 3).
Taking another close look at the OSGi Enterprise spec, I can't say that
this approach is against the spec, it may even be closer to it. I still
do think that Aries' design is more flexible and closer to the OSGi
spirit of modularity and DRY.
At any rate, I'm currently unable to make Aries JPA and Eclipselink work
together. Eclipselink 2.2.0 does not register a PersistenceProvider,
relying on Gemini JPA to do so, but Gemini also creates the EMFs. (see 4).
Eclipselink 2.1.3 does register a PersistenceProvider which throws an
exception when Aries invokes createContainerEntityManagerFactory()
saying that this operation is not supported in OSGi, which I think is
not downright incorrect due to the ambiguity in 5).
So I'm stuck.
I think the bottom line is, for making JPA implementations as pluggable
in OSGi as they are in Java EE, the OSGi JPA spec needs to be more
specific, and mandating a JPA Container as implemented in Aries might be
a good idea.
Regards,
Harald
