openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: OpenJPAPersistence extends Persistence; should we remove this?
Date Wed, 08 Aug 2007 21:01:06 GMT
On 8/8/07, Pinaki Poddar <ppoddar@bea.com> 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: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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message