geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Sat, 12 Aug 2006 00:24:29 GMT

David Blevins wrote:
> On Aug 8, 2006, at 12:22 PM, Jeff Genender wrote:
>> Aaron,
>> Please look at the openejb3-persistence module as it does a majority of
>> what you described below...
>> 1) Takes a classloader
>> 2) looks for persistence.xml files
>> 3) parses found persistence.xml files
>> 4) Creates EntityManagerFactories based on the persistence.xml file
>> specifications.
>> 5) Loads it into JNDI
>> So all you really need to so is provide the classloader and it will
>> handle the rest.  It may need some tweaking, but it should put you in
>> the ballpark of what you need.
> Heads up, going to use all this code.  Likely going to split up the
> PersistenceDeployer class to delay the data source lookup and
> EntityManagerFactory creation till someone tries to lookup it up from
> JNDI.  Basically what I described in my previous email.

Sounds like a good way to handle it.


> -David
>> You can find the code here:
>> Jeff
>> Aaron Mulder wrote:
>>> On 8/8/06, David Blevins <> wrote:
>>>> What approach are you taking to get this done?   I was thinking to do
>>>> App-managed EntityManagers, the EntityManagerFactories looked up
>>>> through JNDI, and available to both web apps and ejbs.
>>> First of all, the work I'm doing on this is mostly helping with the
>>> Geronimo integration... so I'm praying my JPA answers are sensible.
>>> :)
>>> So far the idea is to put an EntityManagerFactory in JNDI for each
>>> persistence unit at java:comp/env/jpa/(persistence-unit-name) .  The
>>> problem is that every component type in Geronimo uses a different
>>> GBean and attribute to hold the JNDI context.  It turns out that Jetty
>>> and Tomcat both use the same attribute name on the WebModule
>>> implementation, which makes that easy.  If you can contribute the
>>> knowhow for EJBs, that would be great -- we just figured web apps were
>>> the low hanging fruit for JPA.
>>>> You make a note about working on an OpenJPA provider, which makes me
>>>> wonder.  The way a JPA provider is plugged in is standard, so you
>>>> shouldn't need to write support for a particular provider.  Any
>>>> details on why that would be required in the code you're working on?
>>> Form a user perspective, it's mainly the necessary configuration
>>> options and documentation.  But on the back end, I expect there's
>>> going to be one JPA plugin with the core logic, and then separate ones
>>> for each provider that set up the class path for that provider and
>>> register with the main JPA plugin.  We haven't yet worked out that
>>> part, but to give a trivial example, Hibernate dies with some kind of
>>> XML gripe if we just add it as a dependency of the current JPA plugin
>>> and try to use it.  So there's going to be some amount of work to get
>>> each provider fully integrated as far as I can tell.
>>>> Regardless, I'm glad I'm not the only one working on this :)
>>> I'll get our code onto SourceForge soon, so this can be a less
>>> theoretical discussion.  :)  In the mean time, have you had any better
>>> ideas as to how to read the persistence.xml and write GBeans into the
>>> web app than to reload and rewrite the serialized Configuration after
>>> the main web app deployer finishes?
>>> Thanks,
>>>     Aaron

View raw message