views:

53

answers:

1

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 Hibernate) but I prefer to program against JPA since I'm in a JEE environment.

A: 

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.

Tassos Bassoukos
I really don't care about having to restart the containers, all I want is to have a universal persistence unit that takes into consideration all of the plugins entities. Thanks for the idea.
Thiado de Arruda