> Technically it's not allowed for entities to be in separate bundles > from the persistence descriptor that uses them, its a violation of > the encapsulation of the data model. It will probably work in most > environments, but only for pre-enhanced entities. I would strongly > recommend not putting entities into a different bundle from the > persistence descriptor, primarily because it is explicitly forbidden > in the JPA service specification.
Yes, the OSGi Enterprise spec requires you to put the whole lot of metadata and entity classes into one bundle, but this simply cries for a change request - after all, OSGi is about modularity... In any non-trivial application, it is quite natural to have the entities and other ingredients for a persistence unit spread across more than one bundle. Some use cases: 1) The common base class example mentioned by Bengt. 2) You have a core bundle A with some entities; this bundle is always active. Then there are two bundles B and C with additional entities with relations to A. Only one of the bundles B or C will be activated at any given time. Each of B and C contains a persistence unit including the entities from A and B (or A and C). 3) You have a strict POJO policy for your entity classes, you loathe JPA annotations anyway and you cannot let your POJO bundle depend on javax.persistence. So you have a model bundle with a bunch of POJOs and no imports, and a persistence bundle which imports your model bundle, javax.persistence if required, and which includes all the XML mapping resources. Actually, no matter what the OSGi spec says, scenario 2) is almost working in my application with OpenJPA. The only problem I had was a theta join query of the sort "select a, b from EntA a, EntB b where a.id = b.id", with EntA and EntB from the bundles A and B, respectively, where OpenJPA was trying to load EntB via the classloader of EntA. (But another query for EntB only did work.) I think all these scenarios would be no problem at all if the JPA provider always used the bundle classloader of the persistence bundle for accessing any class for this persistence unit. > > It should be possible to use EclipseLink with the Aries JPA > container, there were some bugs when we originally tested it, which > we raised against them. I don't know if they've been fixed yet, but > I'd be happy to set up some more itests if you were interested. > Actually, I've just moved away from Eclipselink to OpenJPA due to a number of bugs in JPA 2.0 features.... > The "incompatible" approach taken by EclipseLink is actually the > support that the JPA service specification was built upon. > Meta-Persistence is an OSGi defined header for doing JPA in OSGi, > it's more or less identical to the JPA-PersistenceUnits header. > I'm not sure I'm getting your point - do you mean to say Eclipselink implements a draft version of the spec, and the header was renamed for the final release? Version 4.2 of the OSGi Enterprise spec only mentions Meta-Persistence, and there is no occurrence of "JPA-PersistenceUnits" in that document. Of course, the two headers serve the same purpose, but Aries supports only Meta-Persistence, and Eclipselink 2.1.1 only supports JPA-PersistenceUnits, so in this respect Aries complies with the spec and Eclipselink does not. > I will take this opportunity to say that EclipseLink's OSGi support > is different to the JPA container in Aries. EclipseLink implements > the JPA service specification, which defines unmanaged JPA in OSGi, > Aries uses the same metadata (Meta-Persistence) and spec defined > integration (the PersistenceProvider service) to do container managed > JPA. As a result, the Aries JPA container does not implement a > standard (but does use OSGi standards). Hmmm, let me quote from the spec: 127.1: This specification is about the unmanaged model of JPA except in the areas where the managed model is explicitly mentioned. 127.1.5: A JPA Provider that supports running in managed mode should register a specific service for the Java EE Containers: the Persistence Provider service. 127.2.3: The JPA specifications make a distinction between a managed and an unmanaged mode. In the managed mode the presence of a Java EE Container is assumed. [...] The JPA specifications therefore have defined a special method for Java EE Containers to manage the persistence aspects of their Managed Clients. This method is the createContainerEntityManagerFactory method on the PersistenceProvider interface. This method is purely intended for Java EE Containers and should not be used in other environments. So the OSGi JPA Service spec covers both the managed and the unmanaged case, treating the unmanaged case as default. Aries only uses the container method for creating EntityManagerFactories, which is one of the problems I mentioned earlier in this thread and which it SHOULD not do according to the spec. But a SHOULD NOT is not a SHALL NOT, so I would not say that Aries does not follow the spec (at least not for this reason). > The advantage that Aries has > is that it theoretically works with any JPA provider (barring bugs in > their implementations), whereas as far as I am aware EclipseLink is > the only provider that can be used with the JPA service > specification. Funny, I'm under the impression that I'm currently using OpenJPA and Aries JPA and JNDI in compliance with the spec. Even if Aries does not fully implement the OSGi spec (e.g. the EntityManagerFactoryBuilder service), I don't see anything in my setup explicitly violating the spec. For the time being, I'm happy to have a working solution, but I'm just curious to know where you think Aries really breaks the OSGi JPA spec? Best regards, Harald
