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 Fri, 11 Aug 2006 21:46:27 GMT

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.


> 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