Re: JPA Spec JAR - RE: multiple persistence-units, each w different provider
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 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: users@openjpa.apache.org >>> 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
Re: JPA Spec JAR - RE: multiple persistence-units, each w different provider
What Pinaki mentioned below could be the cause of my error (See Help needed with JBoss and openJPA thread) Do I really need to keep the Geromino.* jars in the lib path of JBoss? Pinaki Poddar 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: users@openjpa.apache.org >> 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? >>> >>> >>> Thanks >>> Adam >>> >>> >> >> >> >> -- >> Patrick Linskey >> 202 669 5907 >> >> >> >> This email and any files transmitted with it are CONFIDEN
Re: JPA Spec JAR - RE: multiple persistence-units, each w different provider
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: users@openjpa.apache.org 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 wh
Re: JPA Spec JAR - RE: multiple persistence-units, each w different provider
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: users@openjpa.apache.org > 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? >> >> >> Thanks >> Adam >> >> > > > > -- > Patrick Linskey > 202 669 5907 > > > > This email and any files transmitted with it are CONFIDENTIAL and > intended > solely for the use of the individual or entity to which they are > addressed. > Any unauthorized copying, disclosure, or distribution of the material > within > this email is strictly forbidden. > Any views or opinions presented within this e-mail are solely those of > the > author and do not necessarily represent those of Odyssey F
JPA Spec JAR - RE: multiple persistence-units, each w different provider
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: users@openjpa.apache.org 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? > > > Thanks > Adam > > -- Patrick Linskey 202 669 5907 This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original.
