[eclipselink-users] PersistenceProvider.createContainerEntityManagerFac

["Philipp Kursawe" <phil.kursawe@xxxxxxxxx>]

Hello,

I once again stumbled over something in EclipseLink that makes me ask if  
this really was designed to be working inside an OSGi environment.
I wanted to have PersistenceExtender that consumes PersistenceUnitInfo  
services in the system.
When such info comes into the system the extender tries to create an  
EntityManagerFactory from it. Not only that this operation results in a  
non-saying NPE its also not understandable why it is not allowed.

How about allowing persistent units come and go naturally inside an OSGi  
eco-system? All my services are consuming EntityManagerFactories already  
with targetting their specific persistent-unit. I would really like to  
kick out the persistence.xml once and for all and create a really dynamic  
system. That seems just not possible with all implementations of JPA  
providers. I had built something like that years ago using Hibernate, but  
I thought JPA would have been evolved since then. Especially since  
EclipseLink is an Eclipse project I wonder why its missing so much of OSGi  
facilities.

The situation is as follow:
I cannot use the persistence.xml for configuration. The user must be able  
to change the config as he wishes. Would it be possible to hand in a  
data-source to EclipseLink *WITHOUT* having to specify this in the  
persistence.xml. Remember. There is NO persistence XML. Each bundle can  
bring in a new persistence unit and new entity classes. I mean I am  
dreaming of extending existing persistence units from bundles... :)

So, whats the current state of EclipseLink in the OSGi world?
The Oracle driver also refuses to load sometimes, for reasons unknown.  
Happens just from time to time. When it happens, it happens in a row of  
several times after each other. Then its normal again.

This post might sound a little negative but EclipseLink (and other JPA  
providers) are giving me a hard time with their inflexibility to work  
inside the OSGi world (that is 10 years old!).

Thanks for reading anyway :) I am happy to read any ideas you might have  
to address the problems,

Phil