geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Tue, 08 Aug 2006 21:18:05 GMT

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

> On 8/8/06, David Blevins <david.blevins@visi.com> 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.

Regarding 1) -- too bad you feel this way.
Regarding 4) -- that's news to me and I can see no reason why that  
would be true.

--kevan

>
>> 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.
>
> Thanks,
>      Aaron


Mime
View raw message