Marina, On 8/8/07, Marina Vatkina <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > Sent: Wednesday, August 08, 2007 1:12 PM > > To: [email protected] > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. >
