Hi, Some comments in line, but broadly speaking I feel your pain. I've been trying to implement automated EclipseLink tests for a long time but can't get them to support EE mode. I'm tempted to provide a shim bundle in Aries to make it work...
Regards, Tim ---------------------------------------- > Date: Sun, 12 Jun 2011 15:33:55 +0200 > From: [email protected] > To: [email protected] > Subject: OSGi JPA Service: Spec and Implementation Mismatch > > 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. > This is true, however the Aries JPA container is *not* an implementation of the JPA service specification. The Aries JPA container actually supports container-managed JPA, which is not part of the JPA Service Specification. This means that you get JTA transaction integration as well as runtime detection and load time enhancement of entity classes (the latter two are only available on 4.3 compliant frameworks). What you don't get is any concept of an EntityManagerFactoryBuilder or JDBC tracking, however we do reuse the Meta-Persistence header, and a lot of the property names, from the JPA service specification. The idea is that for a lot of people Aries is a drop in replacement with better features. It was the original intention of the JPA service spec to offer a container-style extender (like Aries) as well as the unmanaged-style one (like Gemini), but there were a number of missing features in the framework. I worked to get these added in the 4.3 Core spec, and we are now trying to get spec support for the extra features that Aries has. At that point we would definitely aim to implement a "container" part of the JPA service spec. > 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. The idea here is that JPA providers (from JSR-317) can provide a simple OSGi service (the PersistenceProvider implementation) and get OSGi support, rather than all needing to implement duplicate OSGi management code. It's already a pretty big job to write a JPA provider and implement the JPA spec, so it seemed better not to load them with another spec to implement. This way the OSGi alliance hoped that most JPA providers would be usable, rather than just the RI. > 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. Yes, it is possible to do this. It's a lot of work though. This is why the extender was envisaged as being separate. > 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. This actually wouldn't cause a conflict, you are allowed to have multiple services in the service registry. The Aries factories add an extra property to indicate they are container managed. The property is "org.apache.aries.jpa.container.managed". See http://aries.apache.org/modules/jpaproject.html for more information. > 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. OSGi Enterprise is typically Java EE, it defines JTA and Web module standards. As I said in my answer to question 1, the JPA service was substantially cut down in the spec due to missing features. Gemini does the spec (PersistenceProvider.createEntityManagerFactory()), Aries does managed (PersistenceProvider.createContainerEntityManagerFactory()). In my view Aries is much more useful, particularly on a 4.3 framework, because of the JTA integration and framework independent load time enhancement. @PersistenceUnit does not currently work in Aries, though the moment Aries blueprint supports annotations then it will. Technically the spec says "Within a Java EE environment", which does not cover an OSGi framework, but I do take your point. Aries persistence units and persistence contexts are available through dependency injection (like EE) using the blueprint namespace. You can also use JNDI if you like through the "osgi:service" style lookup > 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). Yes, that is what they did. I think it's pretty sucky. > 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. Gemini is the reference implementation for the JPA service spec, so it has to follow it. I think they could do a better job of being JPA provider independent though. > 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). You can use properties to distinguish these, or better yet use blueprint to look up your JPA resources. > 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. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=252263 - I tried to get them to fix this but got no traction. You're actually not completely stuck. One way round this is to repackage/extend EclipseLink to register the org.eclipse.persistence.jpa.PersistenceProvider class as a service in the registry. One simple way would be to add a fragment with some blueprint xml. > 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. >From my answer to question 1. "we are now trying to get spec support for the >extra features that Aries has". I completely agree with you. The current spec >is usable, but the RI is quite tied in to EclipseLink and has a number of >missing EE features. > Regards, > Harald > > > >
