| Re: [eclipselink-users] PersistenceProvider.createContainerEntityManagerFactory not allowed in OSGi? |
|
Hi Philipp, Philipp Kursawe wrote: I once again stumbled over something in EclipseLink that makes me ask if this really was designed to be working inside an OSGi environment.EclipseLink in OSGi is an on-going effort and is something we continue to work on. Since EclipseLink was originally written for the much more forgiving Java SE and EE environments we've had to fix a few bugs relating to classloader usage but other than that it is working. I wanted to have PersistenceExtender that consumes PersistenceUnitInfo services in the system.Perhaps you can post more details on what you're trying to do along with the stack trace? 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.OSGi dynamics is an area we haven't focused on yet. Our principal concern was ensuring that things were working in the simpler "static" case where bundles do not come and go. This is an area I'll be working on after Galileo. I have experimented with what I call a "zero config" bootstrap in which I construct a PersistenceUnitInfo--no persistence.xml. The problem I was addressing was creating a persistence unit for a set of named classes without any xml config or annotations. This code is experimental but I can certainly share it if you're interested. It may give you some ideas. Would it be possible to hand in a data-source to EclipseLink *WITHOUT* having to specify this in the persistence.xml.Yes, you can specify the datasource in the properties map passed to createEntityManagerFactory(). I blogged about this: http://onpersistence.blogspot.com/2008/04/eclipselink-and-datasources.html. There is an OSGi JDBC spec coming that will simplify getting a driver and we'll be supporting that as soon as it's finalized. 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... :)Adding entities to a persistence unit is a more difficult problem. Bryan Hunt (a poster on this list) is also interested in this problem and wants to use the Equinox extension framework to contribute Entities to a PU. I actually think this is quite possible--certainly in the static case. The dynamic case where bundles with Entities come and go is more challenging because of how PUs are initialized. So, whats the current state of EclipseLink in the OSGi world?It works in both Equinox and Felix, it's integrated with EMF in the Tenoe project, dynamic byte code weaving is working in Equinox under certain conditions (it's on my to-do list to document this for Galileo) and we continue to work on it to make it a good OSGi citizen. Right now it lacks in the area of bundle dynamics. 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.I haven't heard about this but I have some updates for the Oracle driver support I'll be getting in soon which may help? Hard to say. We're actually in a really good position with respect to OSGi. All those years of working in various EE containers has ensured the EclipseLink is pretty careful about classloader usage which as everyone knows is critical if you're going to work in OSGi. The fact that we have it working at all so fast is a testament to the code cleanliness. Our challenge has been/is understanding OSGi so we appreciate everyone's patience and assistance as we figure this out. :-) We appreciate your comments! The only way we're going to know what features are of interest to the community is through feedback. And if I've understood you're interested in bootstrapping a persistence unit without a persistence.xml and bundle dynamics. Can you elaborate? In the "no persistence.xml" scenario, where are mappings specified? And in terms of bundle dynamics can you spell out more of what you're thinking? I think the basic case we need to address first is the ability to load, unload, refresh a persistence unit contained in a single bundle. More complex scenarios would follow. Shaun
--
 Shaun Smith | Principal Product Manager Phone: ++19055023094 | | Oracle Oracle Server Technologies, Oracle TopLink ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, Ontario | L5R 3P4 
Oracle is committed to developing practices and products that
help protect the environment
|