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:[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.
