From dev-return-5403-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Thu Aug 09 00:11:58 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 74422 invoked from network); 9 Aug 2007 00:11:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Aug 2007 00:11:57 -0000 Received: (qmail 60688 invoked by uid 500); 9 Aug 2007 00:11:56 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 60658 invoked by uid 500); 9 Aug 2007 00:11:56 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 60649 invoked by uid 99); 9 Aug 2007 00:11:56 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Aug 2007 17:11:56 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.43.132] (HELO sca-es-mail-1.sun.com) (192.18.43.132) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Aug 2007 00:11:48 +0000 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l790BSIo016770 for ; Wed, 8 Aug 2007 17:11:28 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JMH00C01CGADZ00@fe-sfbay-10.sun.com> (original mail from Marina.Vatkina@Sun.COM) for dev@openjpa.apache.org; Wed, 08 Aug 2007 17:11:28 -0700 (PDT) Received: from [129.145.132.161] by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JMH00KNSCJ4OZ30@fe-sfbay-10.sun.com> for dev@openjpa.apache.org; Wed, 08 Aug 2007 17:11:28 -0700 (PDT) Date: Wed, 08 Aug 2007 17:08:54 -0700 From: Marina Vatkina Subject: Re: OpenJPAPersistence extends Persistence; should we remove this? In-reply-to: <89c0c52c0708081418t1a1e9a13ne60b1b5ff6bc6795@mail.gmail.com> Sender: Marina.Vatkina@Sun.COM To: dev@openjpa.apache.org Reply-to: Marina.Vatkina@Sun.COM Message-id: <46BA5B16.30301@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <7262f25e0708080911n236a0335w8130e45730a2343c@mail.gmail.com> <7262f25e0708080939p3567481bgd42b798c1944dc39@mail.gmail.com> <89c0c52c0708081111y7c535af2xd045893f2e69f829@mail.gmail.com> <3992B07C0590B548BB294D31768A1DA2561355@repbex01.amer.bea.com> <46BA249D.6070100@Sun.COM> <89c0c52c0708081418t1a1e9a13ne60b1b5ff6bc6795@mail.gmail.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 X-Virus-Checked: Checked by ClamAV on apache.org They are part of 1.0.2 which is newer than 1.0b. We know it's confusing, but apparently 1.0b was the wrong numbering sequence. thanks, -marina Kevin Sutter wrote: > Marina, > > On 8/8/07, Marina Vatkina wrote: > >>The updated jars are available already in the maven repository. > > > > Are these considered part of the 1.0b version of the Persistence API? Or, > is there a newer version of the API? I noticed that we (OpenJPA) are > pulling in the 1.0b version of the Persistence API. > > Thanks, > Kevin > > -marina > >>Pinaki Poddar wrote: >> >>> > I guess I'm not clear on the static registry problems that have been >>>encountered, >>> >>>The static registry problem is javax.persistence.Persistence class >>>searched for all registered PersistenceProvider, loaded them and cached >>>them in its own *static* variable. >>>In a deploy-undeploy-redeploy scenario, the previously cached versions >>>of >>>PersistenceProvider became invalid. The issue is detailed in [1] and few >>>other usability improvements of Persistence in [2]. >>> >>>The issue had been filed at GlassFish forum and now been resolved. I am >>>not sure when this will be available though. >>> >>>[1] https://glassfish.dev.java.net/issues/show_bug.cgi?id=3229 >>>[2] https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 >>> >>> >>> >>>Pinaki Poddar >>>972.834.2865 >>> >>>-----Original Message----- >>>From: Kevin Sutter [mailto:kwsutter@gmail.com] >>>Sent: Wednesday, August 08, 2007 1:12 PM >>>To: dev@openjpa.apache.org >>>Subject: Re: OpenJPAPersistence extends Persistence; should we remove >>>this? >>> >>>Our experience is that Containers want no knowledge of the specific >>>provider. They need the ability to plug in any provider and the more >>>they can shield themselves from knowing the specific provider, the >>>better. The Persistence class provides this generic interface for >>>creating the EMFactories. My point being that I wouldn't use Container >>>usage as a possible reason for making this separation. >>> >>>I guess I'm not clear on the static registry problems that have been >>>encountered, so I can't really comment on whether making this separation >>>would be buy us anything. >>> >>>Kevin >>> >>>On 8/8/07, Patrick Linskey wrote: >>> >>> >>>>>However, I can't imagine how simply removing the inheritance >>>>>connection would solve anything. Are you suggesting that we >>>>>replicate the Persistence functionality (like >>>>>createEntityManagerFactory()) in our own OpenJPAPersistence class? >>>> >>>>No; I just think that if we weren't ever explicitly linking to it, >>>>then containers / users could do more interesting things with their >>>>classloaders. They'd still be subject to issues with Persistence, but >>>>they could always choose to directly create a PersistenceProviderImpl >>>>and bypass the Persistence class. >>>> >>>>-Patrick >>>> >>>>On 8/8/07, Marc Prud'hommeaux wrote: >>>> >>>> >>>>>Patrick- >>>>> >>>>>I don't know anything about the nature of the problems with the >>>>>Persistence provider registry, but I don't see any reason why >>>>>OpenJPAPersistence should need to extend Persistence. >>>>> >>>>>However, I can't imagine how simply removing the inheritance >>>>>connection would solve anything. Are you suggesting that we >>>>>replicate the Persistence functionality (like >>>>>createEntityManagerFactory()) in our own OpenJPAPersistence class? >>>>> >>>>> >>>>> >>>>>On Aug 8, 2007, at 9:11 AM, Patrick Linskey wrote: >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>We've run into a couple of problems with the static registry >>>>>>maintained in the Persistence class. Should we isolate ourselves >>>>> >>>>>>from it by making OpenJPAPersistence not extend Persistence? If we >>> >>> >>>>>>did so, it would be pretty straightforward for OpenJPA to never >>>>>>reference Persistence, which would mean that people who ran into >>>>>>trouble with that class could work around the problems by using >>>>>>OpenJPA APIs instead. >>>>>> >>>>>>Thoughts? >>>>>> >>>>>>-Patrick >>>>>> >>>>>>-- >>>>>>Patrick Linskey >>>>>>202 669 5907 >>>>> >>>>> >>>>-- >>>>Patrick Linskey >>>>202 669 5907 >>>> >>> >>> >>>Notice: This email message, together with any attachments, may contain >> >>information of BEA Systems, Inc., its subsidiaries and affiliated >>entities, that may be confidential, proprietary, copyrighted and/or >>legally privileged, and is intended solely for the use of the individual or >>entity named in this message. If you are not the intended recipient, and >>have received this message in error, please immediately return this by email >>and then delete it. >> > >