geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: JPA plugin (was Re: Java 1.4 and JEE 5)
Date Tue, 08 Aug 2006 19:23:47 GMT
Is that code in the incubator at Apache now?

Jeff Genender wrote:
> Aaron,
> 
> Please look at the openejb3-persistence module as it does a majority of
> what you described below...
> 
> 1) Takes a classloader
> 2) looks for persistence.xml files
> 3) parses found persistence.xml files
> 4) Creates EntityManagerFactories based on the persistence.xml file
> specifications.
> 5) Loads it into JNDI
> 
> So all you really need to so is provide the classloader and it will
> handle the rest.  It may need some tweaking, but it should put you in
> the ballpark of what you need.
> 
> You can find the code here:
> 
> http://svn.codehaus.org/openejb/trunk/openejb3/container/openejb-persistence/
> 
> Jeff
> 
> 
> Aaron Mulder wrote:
>> On 8/8/06, David Blevins <david.blevins@visi.com> wrote:
>>> What approach are you taking to get this done?   I was thinking to do
>>> App-managed EntityManagers, the EntityManagerFactories looked up
>>> through JNDI, and available to both web apps and ejbs.
>> First of all, the work I'm doing on this is mostly helping with the
>> Geronimo integration... so I'm praying my JPA answers are sensible.
>> :)
>>
>> 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.
>>
>>> You make a note about working on an OpenJPA provider, which makes me
>>> wonder.  The way a JPA provider is plugged in is standard, so you
>>> shouldn't need to write support for a particular provider.  Any
>>> details on why that would be required in the code you're working on?
>> 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.  We haven't yet worked out that
>> part, but to give a trivial example, Hibernate dies with some kind of
>> XML gripe if we just add it as a dependency of the current JPA plugin
>> and try to use it.  So there's going to be some amount of work to get
>> each provider fully integrated as far as I can tell.
>>
>>> Regardless, I'm glad I'm not the only one working on this :)
>> I'll get our code onto SourceForge soon, so this can be a less
>> theoretical discussion.  :)  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?
>>
>> Thanks,
>>     Aaron
> 
> 
> 

Mime
View raw message