Hi, I'm glad that you have a basic application up and running. I have a few comments.
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. As for the JPA provider, there is a minimum level of OSGi awareness necessary. Firstly, it needs to be packaged as an OSGi bundle. Secondly it needs to register its PersistenceProvider implementation in the service registry (using some service properties defined in the JPA service specification). Both of these things are easy for a user to package in, but have already been done by OpenJPA and EclipseLink. If you wanted to to use Hibernate, then you would almost certainly need to re-package it, and use blueprint, DS, or an Activator to register the service. 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. 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 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). 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. Regards, Tim ---------------------------------------- > From: [email protected] > To: [email protected] > Date: Fri, 17 Sep 2010 17:37:01 +0200 > Subject: AW: OSGi JPA and JDBC Services > > Good news: > > - I'm now using the following persistence.xml > > > transaction-type="RESOURCE_LOCAL"> > osgi:service/javax.sql.DataSource > test.openjpa.model.Book > true > > > - I've added the three bundles org.apache.aries.jndi.api, jndi.core and > jndi.url to my application. > > - I have another bundle which imports the appropriate JDBC driver and > publishes a data source as an OSGi service. > > A simple test case with just one entity in the PU bundle now works. > > My real application is a bit more complex, the PU bundle imports entity > classes from two other bundles, and there are custom value handlers which > need to be loaded by OpenJPA in addition to the entity classes. This is the > next thing I'm going to try. > > Just for my better understanding: does the JPA provider have to be OSGi aware > to make this setup work? I.e. does OpenJPA now work with Aries because the > OpenJPA guys have made some additions in the past? Or would the same example > also work with Hibernate or Eclipselink? > > Eclipselink supports OSGi out of the box (while Hibernate notoriously > doesn't), but their approach appears to be slightly incompatible, e.g. they > use a JPA-PersistenceUnits manifest header instead of Meta-Persistence. > > Best regards, > > Harald > > > ________________________________________ > Von: Timothy Ward [[email protected]] > Gesendet: Freitag, 17. September 2010 16:57 > An: [email protected] > Betreff: RE: AW: OSGi JPA and JDBC Services > > You're absolutely right, that was supposed to say 'true' not 'false' - whoops! > > Tim > > ---------------------------------------- >> From: [email protected] >> To: [email protected] >> Date: Fri, 17 Sep 2010 16:53:49 +0200 >> Subject: AW: OSGi JPA and JDBC Services >> >> Hi Tim, >> >> 1. I do enhance my classes at build time. >> 2: I do not list all classes in the persistence.xml. >> >> So I believe you're meaning to say that true would avoid my problem because >> OpenJPA would not need to scan from the persistence unit root. That makes >> sense - I'll give it a try... >> >> Best regards, >> Harald >> >> >> ________________________________________ >> Von: Timothy Ward [[email protected]] >> Gesendet: Freitag, 17. September 2010 16:36 >> An: [email protected] >> Betreff: RE: AW: OSGi JPA and JDBC Services >> >> Hi Harald, >> >> I have two questions: >> >> 1. Are you pre-enhancing your Entity classes? This is a requirement using >> the base Aries JPA container as load-time weaving cannot be supported in a >> generic OSGi framework (although some runtimes extend the Aries code to >> provide this, e.g. Geronimo and WebSphere). >> >> 2. Are you listing all of your entity classes in the persistence unit >> definition and setting false? In unmanaged JPA you are supposed to do this >> (though many providers support scanning in unmanaged environments). In OSGi >> scanning doesn't work the same way, and is, once again, not supported in the >> Aries JPA container (though it is provided in WebSphere). >> >> Both of these limitations will (hopefully) be lifted in the future, but they >> will need to rely on features proposed for version 4.3 of OSGi, and so >> there's not a lot we can do about them at the moment. >> >> Regards, >> >> Tim >>
