openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pinaki Poddar" <ppod...@bea.com>
Subject RE: OpenJPAPersistence extends Persistence; should we remove this?
Date Wed, 08 Aug 2007 18:28:15 GMT
 > 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 <plinskey@gmail.com> 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 <mprudhom@apache.org> 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.

Mime
View raw message