Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 85466 invoked from network); 12 Aug 2006 04:04:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Aug 2006 04:04:57 -0000 Received: (qmail 96194 invoked by uid 500); 12 Aug 2006 04:04:51 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 96156 invoked by uid 500); 12 Aug 2006 04:04:50 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 96145 invoked by uid 99); 12 Aug 2006 04:04:50 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 11 Aug 2006 21:04:50 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [209.181.65.237] (HELO sun.savoirtech.com) (209.181.65.237) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 11 Aug 2006 21:04:49 -0700 Received: from [206.197.197.22] ([206.197.197.22]) (authenticated bits=0) by sun.savoirtech.com (8.13.7/8.13.6) with ESMTP id k7C44QjR022281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 11 Aug 2006 22:04:26 -0600 Message-ID: <44DD53E7.1080704@apache.org> Date: Fri, 11 Aug 2006 22:07:03 -0600 From: Jeff Genender Reply-To: jgenender@apache.org Organization: Apache Geronimo User-Agent: Thunderbird 1.5.0.5 (Macintosh/20060719) MIME-Version: 1.0 To: dev@geronimo.apache.org Subject: Re: JPA plugin (was Re: Java 1.4 and JEE 5) References: <59D9EF7E-8546-48D1-B774-840D73BAC974@visi.com> <74e15baa0608081110j4228e8d0lffb65a25ff4665da@mail.gmail.com> <74e15baa0608111832u1be742c1hcc4a982682f3c916@mail.gmail.com> <44DD3664.2060008@apache.org> <74e15baa0608111859i6af5aa98xe83ee80aae296e79@mail.gmail.com> <44DD3BB2.9070401@apache.org> <74e15baa0608111943ye19f3b3g3c40b299e8c4315a@mail.gmail.com> <44DD45E1.1000700@apache.org> <74e15baa0608112030k7b66dc85o6829ea77223b6348@mail.gmail.com> In-Reply-To: <74e15baa0608112030k7b66dc85o6829ea77223b6348@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on sun.savoirtech.com X-Virus-Scanned: ClamAV 0.88.4/1649/Fri Aug 11 17:44:15 2006 on sun.savoirtech.com X-Virus-Status: Clean X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-105.1 required=5.6 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=3.0.6 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Aaron Mulder wrote: > On 8/11/06, Jeff Genender wrote: >> Ok, I understand where you are going with this. I totally agree with >> your thinking here. But...IIUC...in the web app, if you are including >> your own PU, you likely wouldn't be using the JNDI (and thus the >> container) for this and would be declaring use of the spi bootstrap >> directly: >> >> EntityManagerFactory emf = >> Persistence.createEntityManagerFactory("mywebpersistenceunit") > > But with the plugin we're working on, you can look up app-managed > EntityManagerFactories in JNDI. Even without JNDI, we'd have to > intercept the process to connect the EMF to the DataSource named in > persistence.xml. So when you deploy a web app, we look for a > persistence.xml in order to read all the settings, connect the web app > to the data source and the JPA provider in question, and add the > EntityManagerFactories to JNDI. > > Actually, I'm pretty sure the spec gives examples of a stateless > session bean using app-managed EMFs and they're injected not looked up > the way you're saying. I think that's only for Java SE clients. > Correct...but the spec is assuming a container. My point was...if you included a PU as part of a war, then clearly its not an EJB deployment...thus what is the use for JNDI storage? You could manually store it, but why? IIRC, the injection was for the container...and if used in a stand alone web app (thus assuming JNDI), your access to a war contained PU would be via the spi. > At this moment it won't be a problem, since the plugin only supports > web apps, but with Blevins' expertise it should be easy enough to > support EJB JARs too. Eventually we'll need to get clever -- perhaps > detecting that correctly-named JPA GBeans already exist in the parent > tree so it's not necessary to redefine them for the web app. In fact, > that's probably the way to go. > Right...I see the issue being more of a GBean issue at the end of the day, so I get where you are coming from. > Thanks, > Aaron > > >> And when using the EJB, you would call the JNDI. Therefore, I don't >> think this is a problem at all. >> >> > >> > Thanks, >> > Aaron >> > >> >> But unless >> >> the spi jar uses some sort of mechanism using static declarations or >> >> componanents like Spring, then it really shouldn't be an issue. If it >> >> is, I think its reasonable to claim storage of duplicate PUs in the >> same >> >> package causing the problem (again, like the Spring Commons Logging >> >> problem). >> >> >> >> > >> >> > Thanks, >> >> > Aaron >> >> > >> >> >> Aaron Mulder wrote: >> >> >> > So what happens if an EJB JAR has a persistence.xml and a web >> app in >> >> >> > the same EAR has a separate persistence.xml? If we just look >> in the >> >> >> > class loader, when we go to deploy the web app, we'll see them >> both >> >> >> > because the EJB JAR is added to the parent classpath of the >> WAR. Is >> >> >> > there a good way to distinguish "resource in my ClassLoader" from >> >> >> > "resources in my ClassLoader tree"? >> >> >> > >> >> >> > Thanks, >> >> >> > Aaron >> >> >> >> >> >>