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 repo.maven.org 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]
http://dev2dev.bea.com/blog/pinaki.poddar/archive/2007/06/the_promise_of.html
(see to the end of the post)
[2] https://glassfish.dev.java.net/issues/show_bug.cgi?id=2814 (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
http://mvnrepository.com/artifact/javax.persistence/persistence-api/1.0
from https://glassfish.dev.java.net/javaee5/persistence/
(https://glassfish.dev.java.net/source/browse/glassfish/persistence-api/).
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
http://mirrors.ibiblio.org/pub/mirrors/maven2/javax/persistence/persistence-api/1.0/)
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 [mailto:[EMAIL PROTECTED]
Sent: vendredi, 29. février 2008 01:42
To: [email protected]
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 <[EMAIL PROTECTED]>
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?
