openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pinaki Poddar <>
Subject Re: JPA Spec JAR - RE: multiple persistence-units, each w different provider
Date Mon, 03 Mar 2008 17:47:40 GMT

The patch once submitted in GlassFish forum had moved from priority P1 (how)
to P4 (low) in spite of my objection to such degradation.    

I only hope someone in OpenJPA community will recognize the import of the
fact that the singular entry point to JPA is somewhat broken and needs some
repair and will exert influence to JPA Spec committee to rectify the same.

Adam Hardy-5 wrote:
> Hi Pinaki,
> thanks for the damning indictment of Sun's sloppy practices. You could
> also add 
> to that list the fact that it is coded using goto and labels (unless my 
> decompiler is playing tricks on me) and therefore liable to be coded with 
> similarly dubious quality throughout. Hopefully though it is just a joke
> played 
> by a bored Sun engineer to distress people like me :O
> The issue 2814 and related 3229 are both marked as resolved for milestone 
> 9.1pe_b57 and 3229 says that v1.0.1 has been pushed to maven. I admit
> complete 
> ignorance of the version numbering at Glassfish and how it relates to the 
> persistence-api.jar. There is one at under
> javax.persistence but 
> it is only v1.0 and there's no sign of v1.0.1
> Are you presumably still using your own patch? I'm slightly surprised that 
> there's no alternative out there on maven.
> Regards
> Adam
> Pinaki Poddar on 29/02/08 14:22, wrote:
>> Hi,
>>    javax.persistence.Persistence class as supplied in the distributed
>> version of jpa.jar has more than one shortcomings (in order of descending
>> criticality) :
>> 1. This Persistence class statically caches all the persistence provider
>> implementations. This static caching of implementation classes breaks
>> when
>> an application is undeployed and redeployed again in an Application
>> Server
>> because the classloader of a statically cached version goes out of scope.
>> 2. The error handling in Persistence needs improvement because if any of
>> the
>> provider implementation fails to load then other (possibly valid)
>> providers
>> do not get a chance to activate themselves.
>> 3. The order in which Persistence class attempts to load the providers
>> (as
>> in this reported case) is indeterminate and unspecified. 
>> 4. The error reporting when things go bad (often for the uninitiated)
>> needs
>> to be more informative or user-friendly.
>> This problem has been encountered [1] and I had supplied a patch to
>> GlassFish [2] -- however, I do not know when (or whether) this patch will
>> find its way in the distributed version of jpa.jar.
>> If there is interest, a patch that addresses the abovementioned issues is
>> available with me.
>> Regards --      
>> [1]
>> (see to the end of the post)
>> [2] (the patch
>> in
>> Glassfish repository)
>> Michael Vorburger-4 wrote:
>>> Is there any particular reason why OpenJPA uses the
>>> geronimo-jpa_3.0_spec-1.0.jar instead of the
>>> from
>>> ( 
>>> Is it OSS Licensing mess, use of a CDDL API JAR in a APL libraray a
>>> problem?
>>> BTW: I noticed that the persistence-api-1.0-sources.jar (e.g. from
>>> have JavaDoc... while the geronimo-jpa_3.0_spec-1.0-sources.jar or
>>> geronimo-jpa_3.0_spec-1.0-javadoc.jar don't.  If you use "Source
>>> Attachment" in e.g. Eclipse this is handy...
>>> Would there be any risk if locally we overwrote dependencies so that
>>> developers in our org would use OpenJPA with the persistence-api-1.0.jar
>>> instead of the geronimo-jpa_3.0_spec-1.0.jar (in order to have JavaDoc
>>> Help in Eclipse?).  Probably not - why would there be?  Is this
>>> "allowed"
>>> (more out of curiosity), license wise?  Presumably yes?
>>> Regards,
>>> Michael Vorburger
>>> -----Original Message-----
>>> From: Patrick Linskey [] 
>>> Sent: vendredi, 29. février 2008 01:42
>>> To:
>>> Subject: Re: multiple persistence-units, each w different provider
>>> Hi,
>>> I think that the official copy is the one at Glassfish.
>>> -Patrick
>>> On Thu, Feb 28, 2008 at 2:15 AM, Adam Hardy
>>> <>
>>> wrote:
>>>> I have three persistence-unit nodes in my persistence.xml: one for 
>>>> Toplink with  the toplink provider specified, one for Hibernate, and
>>>> one
>>>> for OpenJPA.
>>>>  It tests various operations in JPA, configured to use whichever JPA 
>>>> supplier I  specify at the time, i.e. I just change the name of the 
>>>> persistence-unit I pass  to Persistence.createEntityManagerFactory().
>>>>  So I have, for instance at the moment, not only openjpa.jar on the 
>>>> classpath,  but also hibernate-entitymanager.jar and
>>>> toplink-essentials.jar.
>>>>  When running my test, due to the way 
>>>> javax.persistence.Persistence.class is  programmed, any of those 
>>>> providers may be picked for use, without reference to  the name of the 
>>>> persistence-unit name that I specified when calling
>>>>  createEntityManagerFactory() - somewhat surprisingly!
>>>>  If my memory serves me well, the persistence-api.jar that I am using 
>>>> is just the  one that maven downloaded automatically from the global
>>>> jar
>>>> repo.
>>>>  I'm tempted to create my own javax.persistence.Persistence to do it 
>>>> properly and  position it ahead of the persistence-api.jar on my
>>>> classpath.
>>>>  This just doesn't seem right. I guess I should be asking at Sun. Was 
>>>> it Sun who  wrote javax.persistence.Persistence ? Or are there 
>>>> different versions? Is there  an 'OpenJPA persistence-api'?
>>>>  Has anyone here written their own and made it publicly available?

View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message