geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Tue, 08 Aug 2006 19:54:49 GMT

David Blevins wrote:
> On Aug 8, 2006, at 12:23 PM, Matt Hogstrom wrote:
>> Is that code in the incubator at Apache now?
> /me hopes matt knew the answer to that question when he did an OpenEJB 
> release yesterday
> :)
>> 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.
>>> 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