openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marina Vatkina <Marina.Vatk...@Sun.COM>
Subject Re: OpenJPAPersistence extends Persistence; should we remove this?
Date Wed, 08 Aug 2007 20:16:29 GMT
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 <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