geronimo-dev mailing list archives

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

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:
>> persistence/
>> 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