Single persistence unit for a modular application (JPA)

I want to create a modular(plugin-like) application that uses JPA as its persistence abstraction, and this application should be extensible by third parties.

The catch is that I want this application and its plugins to be easily portable to other databases/JPA providers, so the third party vendors can't know anything about the used JPA provider(or databases connections), they can only extend the persistence layer by defining new entities to be stored in the main app persistence unit(this would allow one to switch databases without having to reconfigure every module to point to the new db).

Can I do something like that with JPA? I can do it easily with .NET's nHibernate(and probably with H开发者_JS百科ibernate) but I prefer to program against JPA since I'm in a Java EE environment.

Funnily, I have made exactly this using OSGi, Equinox and EclipseLink, but it's not trivial. Essentially, a custom bundle takes all persistence.xml files from all resolved bundles, merges them into a single persistence.xml that is used to initialize the EclipseLink Persistence Provider. Additionally, there are some custom hooks that allow me to specify f.e. connection options separately for development and deployment.

Drawbacks: say bye-bye to container-managed persistence, but it's still possible to join transactions. Also, some tools react violently to cross-bundle entity references. Also, if you add a new bundle with new entities, you will need to have set up the database with the proper tables, references, indexes & constraints beforehand.

Advantages: Drop in new bundle, see it work at once, dynamically, without restarting the container.

I am also researching how to do JPA in a modular way (in the Netbeans module system or in an OSGI container).

One thing you should be aware of is that if you need to build a central, big EntityManagerFactory (by the central persistence module) than you may have some issues if your application is big:

• If the persistence module needs to react to module startup/shutdown events, it needs to rebuild the central EntityManagerFactory when a module is added or removed. If the application is big (lots of classes), rebuilding the EntityManagerFactory is slow and costly.

• The application needs not storing references to the EntityManagerFactory because if a module is added/removed the old one becomes stale. The application should work with very short-lived EntityManager and always get the EntityManagerFactory.

It may be more flexible to build EntityManagerFactories for every JPA-using module, but that may need more memory and may take up more computing power until all of the EntityManagerFactories are created for every module (although EntityManager factories may be created on-demand by your central JPA service).

Dynamic-JPA (http://www.dynamicjava.org/projects/dynamic-jpa) may help if you work in an OSGI container.