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:33:07 GMT
So who is we and why SourceForge?  I can certainly see having  
Hibernate provider plugins and stuff there, but I definitely intend  
on writing the core bits in Geronimo svn.

More bellow... but in a different order.

On Aug 8, 2006, at 11:52 AM, Aaron Mulder wrote:
> 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?

Nothing other than I intend to try and hook the main deployers  
similarly to the way we did for processing the webservice.xml.  Aka,  
whip up some interface, hard code the deployers to call it at a  
logical point in the deployment process.

> 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.

I like the naming convention.  There is a JNDI context attribute  
essentially on each EjbDeployment object -- think OpenEJB 1.0.  In  
the related EjbDeployment GBean it's called "componentContextMap" and  
it's simply a Map that's converted to an ENC via a call to  

> 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.

Sure.  You only attempting to do Application-Managed JPA support  
(EntityManagerFactory objects in JNDI ENCs), so the plugin approach  
will work fine.  When it comes to Container-Managed JPA support  
(proxied EntityManagers in JNDI, tracked by connections and enrolled  
in the transaction context), you're going to have a tougher time.  At  
that point we're more likely to start by taking the connector support  
and expanding it to include JPA.


View raw message