David Blevins wrote: > > On Aug 8, 2006, at 12:22 PM, 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. > > Heads up, going to use all this code. Likely going to split up the > PersistenceDeployer class to delay the data source lookup and > EntityManagerFactory creation till someone tries to lookup it up from > JNDI. Basically what I described in my previous email. >
Sounds like a good way to handle it. Jeff > -David > >> 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 <[EMAIL PROTECTED]> 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 >>
