geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Tue, 08 Aug 2006 19:47:10 GMT
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.

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

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


View raw message