On 8/8/07, Pinaki Poddar <[EMAIL PROTECTED]> 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
Thanks, Pinaki. This history helps with understanding the problems. 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. >
