[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipselink-users] PersistenceProvider.createContainerEntityManagerFactory not allowed in OSGi?
|
On Mon, 06 Apr 2009 17:05:41 +0200, Shaun Smith <shaun.smith@xxxxxxxxxx>
wrote:
Hello Shaun,
first of all, thank you for readting through my rant and your answers!
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.
Perhaps you can post more details on what you're trying to do along with
the stack trace?
The stack trace just contains the NPE. Since I have not the source for the
EclipseLink I am using (from SpringSource) I could only check the binary
and it says something like throw
org.eclipse.persistence.exceptions.EntityManagerSetupException.createContainerEntityManagerFactoryNotSupportedInOSGi().
Thats in version 1.0.1.
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.
Good to hear. I will be able to test several scenarios :)
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.
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.
Sure I would like to take a look at it.
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.
I think I stumbled over this blog entry before. I will have to look again!
Thanks!
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.
I can imagine that the initialization and (possible) table creation is a
big challenge.
Especially if you have to take care of foreign keys and all. Thats
certainly not easy to solve.
Maybe the first step would be to have entities come and go and not create
any tables.
When you have one Entity in Bundle A and another one in Bundle B but they
form or use one FK it will be difficult to decide what to do when one
enters the OSGi system.
However I do not know how the PUs are initialized right now.
Back in the days of Hibernate I just had Hibernate create a new PU when a
new "Eclipse extension" with a Entity came into the system.
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.
Please see my other post about the Oracle driver. Its really driving me
crazy ;)
Is there any start level I should give the driver to be loaded correctly?
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?
Yes thats true. I want to feed all the config data from outside. Have
several bundles that contribute to a PU when they are started. That could
happen through a bundle header or Eclipse Extensions, I would not care
much :) It would be actually enough if the persistence provider would
allow the addition of new Entities during runtime. That would be the first
step. How they end up being added to each PU is up to the programmer. I
could write an extender that would use Eclipse Extensions to add/remove
the Entities to one or multiple PUs.
In the "no persistence.xml" scenario, where are mappings specified?
they would be specified in Eclipse extensions that I load and hand over to
the Persistence Provider.
It should then update all the EMF with the new Entities.
And in
terms of bundle dynamics can you spell out more of what you're
thinking?
I think it should be possible to have several bundles contributing
Entities to one Persistence unit.
If the PU does not exists yet, it will be created. Alongside a EMF will be
created and registered into the system
objectClass=EntityManagerFactory, jpa.pu-name=demo-pu
Other OSGi services could then consume this EMF based on the value of the
jpa.pu-name configuration.
Also it should be possible to switch the datasources without touching the
PUs.
Have a DataSource service in the system that specifies which jpa.pu-names
it is driving. It could certainly drive more than one.
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.
I am with you on this. Just wanted to raise your attention that developing
with JPA in OSGi is still not as easy as it could be.
But also I admit that I am very new to all this JPA so I might not see the
bigger picture sometimes.
Thanks for your efforts!
Phil
