Re: OpenJPA IP clearance (was: Re: [VOTE] publish openjpa 0.9.6-incubating release)
I can take care of the page once we've confirmed that the code was recorded. Geir, you've got more experience with this than I -- any idea where the OpenJPA code grant documented? I didn't find it in grants.txt. Eddie ps -- to update the Incubator website, you need two things: #1: Check this out of SVN: http://svn.apache.org/repos/asf/incubator/public/trunk/ #2: Karma to commit changes and then sync those changes onto /www/incubator.apache.org/projects I think Geir made it this easy a while ago -- nice work. :) On 11/22/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: OpenJPA People- Does anyone have any insight into Eddie's question below (which is in response to point #1 of the objection to the most recent OpenJPA release vote, which can be seen at http://mail-archives.apache.org/ mod_mbox/incubator-general/200611.mbox/% [EMAIL PROTECTED] )? Also, if it is just a matter of updating the http:// incubator.apache.org/projects/openjpa.html page, does anyone know how to go about doing that? AFAIK, since it is not under our project's directory of http://incubator.apache.org/openjpa/ , we can't edit it the same way we can edit our own site. I believe this is the last showstopper for getting through the vote on general@incubator.apache.org (assuming the current vote on open- [EMAIL PROTECTED] passes). On Nov 16, 2006, at 6:20 PM, Eddie O'Neil wrote: On Robert's point about IP clearance, I'd marked that as TODO because I didn't see an obvious place where the code grant for OpenJPA had been recorded from BEA. Geir, do you know where this might be? I did check grants.txt but might have missed it. Thanks. Eddie On 11/16/06, Craig L Russell [EMAIL PROTECTED] wrote: Hi Robert, On Nov 16, 2006, at 12:14 PM, robert burrell donkin wrote: On 11/16/06, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: The OpenJPA incubator community voted on and has approved a proposal to release OpenJPA 0.9.6-incubating. Pursuant to the Releases section of the Incubation Policy (http://incubator.apache.org/incubation/ Incubation_Policy.html#Releases ) we would now like to request the permission of the Incubator PMC to publish the release zip file on the openjpa download page (http://cwiki.apache.org/openjpa/ downloads.html). Proposal: http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200611.mbox/[EMAIL PROTECTED] Vote result: http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200611.mbox/[EMAIL PROTECTED] what's the url for the artifacts to be released? The artifacts are staged at: http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-binary.zip.asc http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-source.zip http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-source.zip.asc http://people.apache.org/repo/m2-incubating-repository/org/apache/ openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6- incubating-source.zip.md5 Is this what you meant? Craig - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/ jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to disable toplink?
Roger- I think the first step would be to get it working in glassfish when deployed globally, and then move from there to seeing if it is possible to deploy it within a WAR. What is the error you get (if any) if you deploy globally? The following persistence.xml worked the last time I tried it: persistence xmlns=http://java.sun.com/xml/ns/persistence; version=1.0 persistence-unit name=pu1 providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider jta-data-sourcejdbc/__default/jta-data-source properties property name=openjpa.Log value=DefaultLevel=TRACE/ property name=openjpa.jdbc.SynchronizeMappings value=buildSchema/ /properties /persistence-unit /persistence On Nov 22, 2006, at 2:57 AM, roger.keays wrote: Hi Marc, Marc Prud wrote: What happens if you put the OpenJPA jars and dependencies in the system classpath of the container? Does it work then? I did try this unsuccessfully on glassfish, although some people have reported that they can get this to work. I'm really looking for a solution that doesn't require the user to hack their container though. Roger If so, then that might be the only solution, currently. IIRC, the spec doesn't say anything about allowing JPA implementations themselves to be bundled into WARs or EARs, so there might no be any generic way to do so (which isn't to say that it's impossible; it might just require some container-specific glue to make it work). On Nov 21, 2006, at 11:59 PM, roger.keays wrote: Is anybody aware of an effective way to ensure that the openjpa jars distributed in a WAR are used for the persistence implementation? I have tried providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider in persistence.xml, and javax.persistence.spi.PersistenceProvider=org.apache.openjpa.persist en ce.PersistenceProviderImpl in the emf properties map but neither appear to work. This problem occurs when deploying to Glassfish, oc4j and (to a lesser extent) Resin (resin provides a buggy ejb30.jar). It seems to be a classloading problem, because these containers load the Persistence.class from their own lib instead of the webapp's. Since that class can't find openjpa, it just falls back to toplink. I had expected the webapp's classes to be loaded in preference to the containers though. Any suggestions? Roger -- View this message in context: http://www.nabble.com/how-to-disable- toplink--tf2683540.html#a7485258 Sent from the open-jpa-dev mailing list archive at Nabble.com. -- View this message in context: http://www.nabble.com/how-to-disable- toplink--tf2683540.html#a7486568 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: how to disable toplink?
Just to note that we have both Toplink and OpenJPA deployed entirely inside a single EAR file under WebSphere 6.1.(which is Java 5 but J2EE 4). We can switch it back and forth between Toplink and OpenJPA modes of operation, without regenerating the EAR, as follows. - change the provider name in persistence.xml. - leave both toplink-essentials.jar and the openjpa jars in the root of the ear at all times - to run in openjpa mode, just update the provider name persistence.xml and in remove the dependency (manifest classpath entry) for toplink-essentials - it is not necessary to remove the dependencies on the openjpa jars when running under toplink. - it is not necessary to ever change any build paths or rebuild The reason that it is necessary to remove the dependency (classpath entry) for toplink when operating in openjpa mode is that otherwise toplink briefly gets control when openjpa enumerates the providers, and at that point toplink gets fatal exceptions because it is not the provider in persistence.xml. When running in toplink mode, toplink enumerates the openjpa provider but openjpa returns control nicely and does nothing when it sees that it has nothing to do! Incidentally, this is somewhat past tense for us because we have now switched to standard operation on OpenJPA and find it superior. So we may soon remove the toplink-essentials jar altogether. Don Marc Prud'hommeaux wrote: Roger- I think the first step would be to get it working in glassfish when deployed globally, and then move from there to seeing if it is possible to deploy it within a WAR. What is the error you get (if any) if you deploy globally? The following persistence.xml worked the last time I tried it: persistence xmlns=http://java.sun.com/xml/ns/persistence; version=1.0 persistence-unit name=pu1 providerorg.apache.openjpa.persistence.PersistenceProviderImpl/provider jta-data-sourcejdbc/__default/jta-data-source properties property name=openjpa.Log value=DefaultLevel=TRACE/ property name=openjpa.jdbc.SynchronizeMappings value=buildSchema/ /properties /persistence-unit /persistence On Nov 22, 2006, at 2:57 AM, roger.keays wrote: Hi Marc, Marc Prud wrote: What happens if you put the OpenJPA jars and dependencies in the system classpath of the container? Does it work then? I did try this unsuccessfully on glassfish, although some people have reported that they can get this to work. I'm really looking for a solution that doesn't require the user to hack their container though. Roger If so, then that might be the only solution, currently. IIRC, the spec doesn't say anything about allowing JPA implementations themselves to be bundled into WARs or EARs, so there might no be any generic way to do so (which isn't to say that it's impossible; it might just require some container-specific glue to make it work). On Nov 21, 2006, at 11:59 PM, roger.keays wrote: Is anybody aware of an effective way to ensure that the openjpa jars distributed in a WAR are used for the persistence implementation? I have tried providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider in persistence.xml, and javax.persistence.spi.PersistenceProvider=org.apache.openjpa.persisten ce.PersistenceProviderImpl in the emf properties map but neither appear to work. This problem occurs when deploying to Glassfish, oc4j and (to a lesser extent) Resin (resin provides a buggy ejb30.jar). It seems to be a classloading problem, because these containers load the Persistence.class from their own lib instead of the webapp's. Since that class can't find openjpa, it just falls back to toplink. I had expected the webapp's classes to be loaded in preference to the containers though. Any suggestions? Roger --View this message in context: http://www.nabble.com/how-to-disable- toplink--tf2683540.html#a7485258 Sent from the open-jpa-dev mailing list archive at Nabble.com. --View this message in context: http://www.nabble.com/how-to-disable-toplink--tf2683540.html#a7486568 Sent from the open-jpa-dev mailing list archive at Nabble.com.
Re: how to disable toplink?
I looked at the code in javax.persistence.Persistence.createEntityManagerFactory and it iterates the META-INF/services/ javax.persistence.spi.PersistenceProvider using the context class loader. So, first assumption: you are using the Persistence.createEntityManagerFactory method in your servlet init method to locate the EMF. The issue with this is in Persistence. The results of finding the services the very first time is cached in a static variable. The only way I can see to make this work is to use your own version of Persistence that is also deployed in your WAR file. If you use the Persistence.class that is shared in the server, you can never see the provider in your WAR file. So you would have to use the non- delegating WAR file loader along with your own copy of the persistence.jar that contains Persistence.class. If you use the server's JNDI lookup, or put the OpenJPA jar file into the server's shared library, you should be able to avoid this issue. Craig On Nov 22, 2006, at 10:58 AM, Patrick Linskey wrote: My read of the spec is that while this deployment isn't explicitly called out, it certainly is strongly implied, and at the very least an appserver should provide clear instructions for how to deploy OpenJPA for use in such an environment. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ 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. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Tuesday, November 21, 2006 11:25 PM To: open-jpa-dev@incubator.apache.org Subject: Re: how to disable toplink? Roger- What happens if you put the OpenJPA jars and dependencies in the system classpath of the container? Does it work then? If so, then that might be the only solution, currently. IIRC, the spec doesn't say anything about allowing JPA implementations themselves to be bundled into WARs or EARs, so there might no be any generic way to do so (which isn't to say that it's impossible; it might just require some container-specific glue to make it work). On Nov 21, 2006, at 11:59 PM, roger.keays wrote: Is anybody aware of an effective way to ensure that the openjpa jars distributed in a WAR are used for the persistence implementation? I have tried providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider in persistence.xml, and javax.persistence.spi.PersistenceProvider=org.apache.openjpa.p ersisten ce.PersistenceProviderImpl in the emf properties map but neither appear to work. This problem occurs when deploying to Glassfish, oc4j and (to a lesser extent) Resin (resin provides a buggy ejb30.jar). It seems to be a classloading problem, because these containers load the Persistence.class from their own lib instead of the webapp's. Since that class can't find openjpa, it just falls back to toplink. I had expected the webapp's classes to be loaded in preference to the containers though. Any suggestions? Roger -- View this message in context: http://www.nabble.com/how-to-disable- toplink--tf2683540.html#a7485258 Sent from the open-jpa-dev mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
RE: Two more release artifacts for next time
Shouldn't Maven have some way to just do that declaratively, so that the Maven framework can go and fetch the other dependencies? -Patrick -- Patrick Linskey BEA Systems, Inc. ___ 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 5:43 PM To: open-jpa-dev@incubator.apache.org Subject: Two more release artifacts for next time Hi, I'd like to propose distributing two artifacts in addition to the binary and source releases we already are voting on. The two artifacts are the complete with dependencies jar and the everything openjpa jar. This way, folks who use maven (either 1 or 2) can take advantage of the dependency downloads that maven is famous for. Simply, if a user has a maven project they can add openjpa as a dependency and they are done. Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: Two more release artifacts for next time
Yes. In maven1, you need the everything jar or you have to declare all of openjpa's dependencies. In maven2, you need just the openjpa jar and its pom declares its own dependencies. Craig On Nov 22, 2006, at 5:45 PM, Patrick Linskey wrote: Shouldn't Maven have some way to just do that declaratively, so that the Maven framework can go and fetch the other dependencies? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 5:43 PM To: open-jpa-dev@incubator.apache.org Subject: Two more release artifacts for next time Hi, I'd like to propose distributing two artifacts in addition to the binary and source releases we already are voting on. The two artifacts are the complete with dependencies jar and the everything openjpa jar. This way, folks who use maven (either 1 or 2) can take advantage of the dependency downloads that maven is famous for. Simply, if a user has a maven project they can add openjpa as a dependency and they are done. Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
Re: how to disable toplink?
Craig L Russell wrote: The issue with this is in Persistence. The results of finding the services the very first time is cached in a static variable. The only way I can see to make this work is to use your own version of Persistence that is also deployed in your WAR file. If you use the Persistence.class that is shared in the server, you can never see the provider in your WAR file. So you would have to use the non- delegating WAR file loader along with your own copy of the persistence.jar that contains Persistence.class. That was my original plan, but it seems that you can't actually do this since, according to SRV2.4 #9.7.2: servlet containers that are part of a J2EE product should not allow the application to override J2SE or J2EE platform classes, such as those in java.* and javax.* namespaces, that either J2SE or J2EE do not allow to be modified. So the container is right to load it's own Persistence.class instead of yours, and the only correct way is to install the persistence provider into the container itself. Unless of course you just... PersistenceProvider provider = new org.apache.openjpa.persistence.PersistenceProviderImpl(); EntityManagerFactory emf = provider.createEntityManagerFactory(default); :) (note, I'm not using dependency injection here) If you use the server's JNDI lookup, or put the OpenJPA jar file into the server's shared library, you should be able to avoid this issue. Craig On Nov 22, 2006, at 10:58 AM, Patrick Linskey wrote: My read of the spec is that while this deployment isn't explicitly called out, it certainly is strongly implied, and at the very least an appserver should provide clear instructions for how to deploy OpenJPA for use in such an environment. -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ 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. -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Tuesday, November 21, 2006 11:25 PM To: open-jpa-dev@incubator.apache.org Subject: Re: how to disable toplink? Roger- What happens if you put the OpenJPA jars and dependencies in the system classpath of the container? Does it work then? If so, then that might be the only solution, currently. IIRC, the spec doesn't say anything about allowing JPA implementations themselves to be bundled into WARs or EARs, so there might no be any generic way to do so (which isn't to say that it's impossible; it might just require some container-specific glue to make it work). On Nov 21, 2006, at 11:59 PM, roger.keays wrote: Is anybody aware of an effective way to ensure that the openjpa jars distributed in a WAR are used for the persistence implementation? I have tried providerorg.apache.openjpa.persistence.PersistenceProviderImpl/ provider in persistence.xml, and javax.persistence.spi.PersistenceProvider=org.apache.openjpa.p ersisten ce.PersistenceProviderImpl in the emf properties map but neither appear to work. This problem occurs when deploying to Glassfish, oc4j and (to a lesser extent) Resin (resin provides a buggy ejb30.jar). It seems to be a classloading problem, because these containers load the Persistence.class from their own lib instead of the webapp's. Since that class can't find openjpa, it just falls back to toplink. I had expected the webapp's classes to be loaded in preference to the containers though. Any suggestions? Roger -- View this message in context: http://www.nabble.com/how-to-disable- toplink--tf2683540.html#a7485258 Sent from the open-jpa-dev mailing list archive at Nabble.com. Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! -- View this message in context: http://www.nabble.com/how-to-disable-toplink--tf2683540.html#a7500820 Sent from the open-jpa-dev mailing list archive at Nabble.com.
RE: Two more release artifacts for next time
Do we care about supporting Maven 1 artifacts? I know nothing about maven, including what versions people use out there. My uneducated opinion is that we should not do extra work for old-version support if we can get away with it. -Patrick -- Patrick Linskey BEA Systems, Inc. ___ 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 9:26 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Two more release artifacts for next time Yes. In maven1, you need the everything jar or you have to declare all of openjpa's dependencies. In maven2, you need just the openjpa jar and its pom declares its own dependencies. Craig On Nov 22, 2006, at 5:45 PM, Patrick Linskey wrote: Shouldn't Maven have some way to just do that declaratively, so that the Maven framework can go and fetch the other dependencies? -Patrick -- Patrick Linskey BEA Systems, Inc. __ _ 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. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 22, 2006 5:43 PM To: open-jpa-dev@incubator.apache.org Subject: Two more release artifacts for next time Hi, I'd like to propose distributing two artifacts in addition to the binary and source releases we already are voting on. The two artifacts are the complete with dependencies jar and the everything openjpa jar. This way, folks who use maven (either 1 or 2) can take advantage of the dependency downloads that maven is famous for. Simply, if a user has a maven project they can add openjpa as a dependency and they are done. Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdo Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
