You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Dennis Thrysøe <dt...@conscius.com> on 2007/05/14 21:40:35 UTC
Embedding OpenJPA
Hello,
I'm planning on embedding OpenJPA in a server (which is running in a
J2EE environment). OpenJPA will run entirely within this server, and
together with added functionality implement a "content container" in
which entities can be depolyed, just as servlets can in a servlet container.
So, I was wondering if anybody here could help me get a little wiser on
OpenJPA. Does OpenJPA:
- Allow arbitrary instatiation and destruction, without requiring
anything directly from the J2EE framework?
- Allow dynamic deployment of Entities when they are loaded, or at
deployment time.
- Allow "third parties" (not the entity definitions) to define/override
things such as identity definition, field types (convert when
reading/writing etc.?
Any thoughts welcome.
-dennis
---------------------------------------------------------------------------
The information in this email is confidential and may be legally protected.
Re: Embedding OpenJPA
Posted by Patrick Linskey <pl...@gmail.com>.
> That sounds like the right way to do it. So my container would, on
> startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke
> createContainerEntityManagerFactory() with a PersistenceUnitInfo that I
> implement?
Yes. Note that OpenJPA already has an PUInfo implementation that you
might want to take advantage of.
> I can see that this gives me a great deal of control over classloading,
> transactions, etc. But it looks like I still need to supply all managed
> class names up front, and must refer to mapping information as file
> references?
Not necessarily -- OpenJPA supports dynamically discovering new
classes as they are loaded, so you could certainly take advantage of
that.
Some things cannot be done until after OpenJPA has loaded a class. For
example, you cannot use a class's alais in a JPQL query until after
the class has been bootstrapped, and any named queries defined on the
class will not be visible until the class has been loaded.
I can't remember exactly how things work; it's possible that if you
list classes, then OpenJPA assumes that that is a complete list and
doesn't support lazy discovery of classes.
> I am hoping for a way to enhance and register classes as appropriate at
> ordinary classloading time, or if that isn't possible at least discover
> the classes dynamically at deployment time. Generally I'm trying to
> avoid using persistence.xml.
Why? Are you trying to reduce it's complexity, or just eliminate it
altogether? How do you propose having your users configure things like
OpenJPA logging or tuning options? If you're planning on
re-introducing a significant percentage of these things, then you
might want to consider just using persistence.xml, but limiting which
parts can be used.
> Likewise the mapping information should only come from annotations on
> the managed classes, but ideally through "me" such that certain things
> can be changed on the fly (such as field value and type conversion etc.)
What degree of control do you want? Control over defaults etc., or the
ability to override what the user specified? You can get a pretty
complete amount of control by implementing a MappingFactory;
presumably your implementation would delegate to the normal mapping
factory.
-Patrick
On 5/16/07, Dennis Thrysøe <dt...@conscius.com> wrote:
> Patrick Linskey wrote:
> > This means that your container would be responsible for EntityManager
> > lifecycle and potentially for transaction control. It also means that
> > you'd interact with OpenJPA via the
> > PersistenceProvider.createContainerEntityManagerFactory() API. In such
> > a scenario, you (the container) would be responsible for providing a
> > PersistenceUnitInfo (you might want to take advantage of OpenJPA's
> > existing XML-processing support to help out with this).
>
> That sounds like the right way to do it. So my container would, on
> startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke
> createContainerEntityManagerFactory() with a PersistenceUnitInfo that I
> implement?
>
> I can see that this gives me a great deal of control over classloading,
> transactions, etc. But it looks like I still need to supply all managed
> class names up front, and must refer to mapping information as file
> references?
>
> I am hoping for a way to enhance and register classes as appropriate at
> ordinary classloading time, or if that isn't possible at least discover
> the classes dynamically at deployment time. Generally I'm trying to
> avoid using persistence.xml.
>
> Likewise the mapping information should only come from annotations on
> the managed classes, but ideally through "me" such that certain things
> can be changed on the fly (such as field value and type conversion etc.)
>
> Is this possible? Perhaps by providing certain properties in the map
> when obtaining an EntityManagerFactory? Or am I being too creative here?
>
> -dennis
> ---------------------------------------------------------------------------
> The information in this email is confidential and may be legally protected.
>
>
--
Patrick Linskey
202 669 5907
Re: Embedding OpenJPA
Posted by Dennis Thrysøe <dt...@conscius.com>.
Patrick Linskey wrote:
> This means that your container would be responsible for EntityManager
> lifecycle and potentially for transaction control. It also means that
> you'd interact with OpenJPA via the
> PersistenceProvider.createContainerEntityManagerFactory() API. In such
> a scenario, you (the container) would be responsible for providing a
> PersistenceUnitInfo (you might want to take advantage of OpenJPA's
> existing XML-processing support to help out with this).
That sounds like the right way to do it. So my container would, on
startup, instantiate OpenJPA's PersistenceProviderImpl, and invoke
createContainerEntityManagerFactory() with a PersistenceUnitInfo that I
implement?
I can see that this gives me a great deal of control over classloading,
transactions, etc. But it looks like I still need to supply all managed
class names up front, and must refer to mapping information as file
references?
I am hoping for a way to enhance and register classes as appropriate at
ordinary classloading time, or if that isn't possible at least discover
the classes dynamically at deployment time. Generally I'm trying to
avoid using persistence.xml.
Likewise the mapping information should only come from annotations on
the managed classes, but ideally through "me" such that certain things
can be changed on the fly (such as field value and type conversion etc.)
Is this possible? Perhaps by providing certain properties in the map
when obtaining an EntityManagerFactory? Or am I being too creative here?
-dennis
---------------------------------------------------------------------------
The information in this email is confidential and may be legally protected.
Re: Embedding OpenJPA
Posted by Patrick Linskey <pl...@gmail.com>.
Hi Dennis,
If you don't want to use your Java EE's JPA integration features, you
might want to look at setting things up so that your content container
is generally a "persistence container" in the parlance of the JPA
spec.
This means that your container would be responsible for EntityManager
lifecycle and potentially for transaction control. It also means that
you'd interact with OpenJPA via the
PersistenceProvider.createContainerEntityManagerFactory() API. In such
a scenario, you (the container) would be responsible for providing a
PersistenceUnitInfo (you might want to take advantage of OpenJPA's
existing XML-processing support to help out with this).
The benefit of doing this is that it would provide the JPA consumers
(your internal team and extenders of your product) with runtime and
deployment semantics similar to what the JPA spec already does,
possibly with your own tweaks here and there to support additional
features.
-Patrick
On 5/14/07, Dennis Thrysøe <dt...@conscius.com> wrote:
> Hello,
>
> I'm planning on embedding OpenJPA in a server (which is running in a
> J2EE environment). OpenJPA will run entirely within this server, and
> together with added functionality implement a "content container" in
> which entities can be depolyed, just as servlets can in a servlet container.
>
> So, I was wondering if anybody here could help me get a little wiser on
> OpenJPA. Does OpenJPA:
>
> - Allow arbitrary instatiation and destruction, without requiring
> anything directly from the J2EE framework?
> - Allow dynamic deployment of Entities when they are loaded, or at
> deployment time.
> - Allow "third parties" (not the entity definitions) to define/override
> things such as identity definition, field types (convert when
> reading/writing etc.?
>
> Any thoughts welcome.
>
> -dennis
> ---------------------------------------------------------------------------
> The information in this email is confidential and may be legally protected.
>
>
--
Patrick Linskey
202 669 5907
Re: Embedding OpenJPA
Posted by Kevin Sutter <kw...@gmail.com>.
Dennis,
Welcome to OpenJPA! Comments below... Kevin
On 5/14/07, Dennis Thrysøe <dt...@conscius.com> wrote:
>
> Hello,
>
> I'm planning on embedding OpenJPA in a server (which is running in a
> J2EE environment). OpenJPA will run entirely within this server, and
> together with added functionality implement a "content container" in
> which entities can be depolyed, just as servlets can in a servlet
> container.
>
> So, I was wondering if anybody here could help me get a little wiser on
> OpenJPA. Does OpenJPA:
>
> - Allow arbitrary instatiation and destruction, without requiring
> anything directly from the J2EE framework?
Yes. Actually, the JPA specification requires this separation from the J2EE
framework and containers. The basic programming model is exactly the same
between the SE and EE environments.
- Allow dynamic deployment of Entities when they are loaded, or at
> deployment time.
Yes. OpenJPA allows for either static enhancement (deployment) of Entities
at build time or dynamic enhancement of Entities at runtime. This dynamic
enhancement can be kicked off either via a Java agent in an SE envrionment,
or via a classloader plugin in a Container environment.
- Allow "third parties" (not the entity definitions) to define/override
> things such as identity definition, field types (convert when
> reading/writing etc.?
Yes. The JPA spec outlines both annotation and xml descriptors for the
Entity definitions. There are a few OpenJPA-specific annotations that are
currently not configurable via xml, but that will eventually be resolved
(OPENJPA-125).
Any thoughts welcome.
>
> -dennis
>
> ---------------------------------------------------------------------------
> The information in this email is confidential and may be legally
> protected.
>
>