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 20:43:51 GMT

On Aug 8, 2006, at 12:47 PM, Aaron Mulder wrote:

> On 8/8/06, David Blevins <> wrote:
>> 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.
> "we" is myself and some folks at Chariot.  At SourceForge because 1)
> we need some place to collaborate on the code and that's impossible
> under RTC, 2) we are working primarily with TopLink during development
> and that's impossible at Apache, 3) it was easier to set up a
> SourceForge project than Codehaus and I don't know what to make of
> Google, and 4) I was explicitly told that plugin development should be
> done outside of Apache.

That's cool.  Maybe we can still work something out in terms of  
provider wrappers.  Who knows.

>> 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.
> We're targeting Geronimo 1.1, which means we only have what we have,
> and I think I have to do it the ugly way.
> If we're talking about future releases, I strongly oppose adding
> another hardcoded "deployment helper".  I think we need a generic list
> of auxilliary deployers that can get invoked every time a J2EE
> application module is deployed.  For example, the Quartz plugin lets
> you include scheduled jobs in a WAR and so it needs to hook into the
> WAR deployment process too.  As long as we have all these various
> things that want to do that, let's make it pluggable.

I agree we need a better way, but that's not a feature I plan on  
working on.

>> 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
>> "EnterpriseNamingContext.createEnterpriseNamingContext"
> OK, that sounds easy enough.  But if you have one
> META-INF/persistence.xml file in your EJB JAR, how do you know which
> EJBs should get the JNDI entries?  Or is there some convention to map
> individual EJBs to differently-named persistence.xml files, or to map
> persistence units in persistence.xml to individual EJBs?

Was just going to shove it in every ENC as anything else would  
require us to start supporting the EJB 3 ejb-jar.xml.

>> 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.
> Yeah, not targeting container-managed JPA support with this plugin.
> We are using a Geronimo DB pool for persistence, though.  So doesn't
> that mean it would be included in any transaction that was going on
> already?  Not too relevant for web apps, but would JPA in a Session
> Bean inherit the Session Bean transaction settings?  I'm not sure at
> what point in the process the DataSource or Connection notices that
> there's a transaction going on and enlists itself.

You probably don't want to do that.  That would only work if the  
Persistence provider did zero caching.  You really can't go swapping  
out the connections underneath an EntityManager that caches.  It is  
relevant to webapps too as they are allowed to create an  
EntityManager from the EntityManagerFactory, call begin transaction  
on it, shove it in to the Session, and pull it out at a later request  
and call commit on it.


View raw message