geronimo-dev mailing list archives

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

On Aug 8, 2006, at 1:43 PM, David Blevins wrote:

> 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 agree we need something like this.  The namespace driven builders  
in the pluggable jacc patch would probably work for your quartz  
plugin (i.e. you can put a new namespace/xml into any g. plan in the  
"gbean section" and if there's a registered builder for it, it will  
get picked up).  Doing something like this for j2ee supported stuff  
is a lot harder since you have to deal with 2 sets of xml, at least  
one of which might not be there at all.  The SwitchingModuleBuilder  
is as far as I've gotten in this direction.

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

I'm don't understand the tx support in jpa yet.  To get container  
managed to work you definitely need the new tx manager interface to  
get the cache flushed.  Maybe theres a way to explicitly flush the  
jpa cache in which case you could use UserTx around the whole thing.   
If jpa can actually control tx itself you should be using a no-tx db  

david jencks

> -David

View raw message