aries-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Ward <>
Subject RE: AW: OSGi JPA and JDBC Services
Date Sun, 19 Sep 2010 20:27:21 GMT

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

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!


> From:
> To:
> 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
> 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 =", 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
>> 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
> This method is the createContainerEntityManagerFactory method on the PersistenceProvider
> This method is purely intended for Java EE Containers and should not be used in other
> 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
View raw message