Hi Harald, As I said to Bengt earlier, there are many significant issues around supporting entities spread across multiple bundles, including but not limited to load-time enhancement and sharing between multiple providers. There is also an extremely tight coupling between a persistence unit and its entity classes, one which dpesn't tie well with a split between bundles.
I agree that it is a particularly restrictive restriction, but the aim of OSGi specifications is to define features that can be used reliably and portably, particularly with respect to ordering. Item 3) that you mention is supported in the current model, it is not necessary to import javax.persistence if you only use xml definitions. Finally, I don't think that I said at any point that the Aries runtime violates the JPA service specification, only that it doesn't implement it. I would strongly hope that we don't violate any of the JPA or JPA service specifications, as future versions of the JPA service specification should include full support for managed JPA and I would like it to be based on our container! Regards Tim ---------------------------------------- > From: [email protected] > To: [email protected] > Date: Sun, 19 Sep 2010 18:18:03 +0200 > Subject: AW: OSGi JPA and JDBC Services > >> 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
