You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2007/08/08 18:11:55 UTC
OpenJPAPersistence extends Persistence; should we remove this?
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
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Kevin Sutter <kw...@gmail.com>.
On 8/8/07, Pinaki Poddar <pp...@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 <pl...@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 <mp...@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.
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Marina Vatkina <Ma...@Sun.COM>.
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 <Ma...@sun.com> 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 <pl...@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 <mp...@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.
>>
>
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Kevin Sutter <kw...@gmail.com>.
Marina,
On 8/8/07, Marina Vatkina <Ma...@sun.com> 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 <pl...@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 <mp...@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.
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Marina Vatkina <Ma...@Sun.COM>.
The updated jars are available already in the maven repository.
-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 <pl...@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 <mp...@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.
RE: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Pinaki Poddar <pp...@bea.com>.
> 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 <pl...@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 <mp...@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.
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Kevin Sutter <kw...@gmail.com>.
Marina,
On 8/8/07, Marina Vatkina <Ma...@sun.com> wrote:
>
> Kevin,
>
> Are you talking about Java EE 5 containers or J2EE4 and pure
> web-containers? The
> formers should not use Persistence class to load container-managed
> persistence
> units (according to the spec).
You are right. I was confusing this with the PersistenceProvider spi.
Thanks for clarifying.
Kevin
thanks,
> -marina
>
> Kevin Sutter wrote:
> > 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 <pl...@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 <mp...@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
> >>
> >
> >
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Marina Vatkina <Ma...@Sun.COM>.
Kevin,
Are you talking about Java EE 5 containers or J2EE4 and pure web-containers? The
formers should not use Persistence class to load container-managed persistence
units (according to the spec).
thanks,
-marina
Kevin Sutter wrote:
> 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 <pl...@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 <mp...@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
>>
>
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Kevin Sutter <kw...@gmail.com>.
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 <pl...@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 <mp...@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
>
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Patrick Linskey <pl...@gmail.com>.
> 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 <mp...@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
Re: OpenJPAPersistence extends Persistence; should we remove this?
Posted by Marc Prud'hommeaux <mp...@apache.org>.
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