Re: [jira] Commented: (INFRA-1245) Create new TLP OpenJPA
So far so good. Thanks for handling this. One issue I see with the automatic update is that we're subject to spam being automatically propagated to our main web site. If we leave the mprudhom cron job off we are more in control, although it would mean we would have to remember to rsync the site whenever one of us made a change to the wiki that we wanted to propagate to the main web site. But it would give us a chance to fix the errant wiki pages before they were published to the world from our official site. Craig On May 25, 2007, at 11:45 PM, Marc Prud'hommeaux wrote: OK, I've set this up. The system is basically the same as the convoluted setup for exporting to the old incubator.apache.org site: 1. My personal crontab runs /www/openjpa.apache.org/RSYNCSITE.sh (it would be nice to have an openjpa user so this isn't tied to my personal user account). 2. RSYNCSITE.sh runs: rsync -a /home/jefft/public_html/confluence/ openjpa/* /www/openjpa.apache.org/ (note that /home/jefft/ public_html/confluence/ appears to contain an automatic sync of all the confluence exported sites, so I didn't see any need to set up an additional one). 3. Once the stuff is at /www/openjpa.apache.org/, some other process (unknown to me) seems to periodically sync that directory content to a place where it actually shows up at http:// openjpa.apache.org/ . I've also set up redirects from all the old html pages from http:// incubator.apache.org/openjpa/ to go to http://openjpa.apache.org , so links should be redirected appropriately. E.g., if you do to: http://incubator.apache.org/openjpa/downloads.html you should be redirected to: http://openjpa.apache.org/downloads.html Please let me know if anyone runs into any problems with this. On May 25, 2007, at 11:19 AM, Craig L Russell wrote: Thank you thank you thank you. Can you make sure you can edit the people.apache.org /www/ openjpa.apache.org directory (need to be in the openjpa unix group) to facilitate your work later? All the committers should be in the unix openjpa group already but this is part of the migration so it might not be set up yet. Craig On May 25, 2007, at 11:12 AM, Marc Prud'hommeaux wrote: I'll try to look into this sometime this evening (PST). On May 25, 2007, at 11:07 AM, Joshua Slive wrote: On 5/25/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Joshua, I would appreciate some help here. I have no time to troll through all other Apache web sites looking for models. Is there a quick 1-pager on how to symlink the OpenJPA confluence web site to be our www web site? Or another project that does so with a public www/projectnamehere that I can model? Sorry, but your confluence guys need to come up with the procedures yourself. I don't use confluence. I can only tell you what is required to have a reliable, maintainable apache infrastructure. But you can probably use the instructions from http://cwiki.apache.org/CWIKI/ just replacing the ~jefft location with the location under /www/confluence-exports. Joshua. 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! 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: [jira] Commented: (INFRA-1245) Create new TLP OpenJPA
Hi, On May 25, 2007, at 6:39 AM, Joshua Slive wrote: On 5/24/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Brett, On May 24, 2007, at 7:09 PM, Brett Porter wrote: That's better, but the content is actually rsynced to people.apache.org as well, so you're far better off either copying that or symlinking it. This is well documented here: http:// cwiki.apache.org/CWIKI/ I'll check this out when I get some breathing room. As long as the site isn't broken, I'm happy for now. Although it doesn't need to be done in the next 10 minutes, fixing this should be a priority. It is an infrastructure requirement that the content of your main website lives on minotaur. Otherwise our mirroring and backup system does not function as designed. Can you please give me a link to this requirement? I had not know of it until just now. Brett provided a link above, which I haven't yet had time to read. If this is not sufficient to perform the task, if you can give me some pointers on how to accomplish it this will also help. We do want the site content to be the wiki static site so some specific ideas on how to do this will give us some specific action items. Thanks, Craig Joshua. 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: [jira] Commented: (INFRA-1245) Create new TLP OpenJPA
Hi Joshua, I would appreciate some help here. I have no time to troll through all other Apache web sites looking for models. Is there a quick 1-pager on how to symlink the OpenJPA confluence web site to be our www web site? Or another project that does so with a public www/projectnamehere that I can model? Thanks, Craig On May 25, 2007, at 7:24 AM, Joshua Slive wrote: On 5/25/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi, On May 25, 2007, at 6:39 AM, Joshua Slive wrote: On 5/24/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Brett, On May 24, 2007, at 7:09 PM, Brett Porter wrote: That's better, but the content is actually rsynced to people.apache.org as well, so you're far better off either copying that or symlinking it. This is well documented here: http:// cwiki.apache.org/CWIKI/ I'll check this out when I get some breathing room. As long as the site isn't broken, I'm happy for now. Although it doesn't need to be done in the next 10 minutes, fixing this should be a priority. It is an infrastructure requirement that the content of your main website lives on minotaur. Otherwise our mirroring and backup system does not function as designed. Can you please give me a link to this requirement? I had not know of it until just now. I don't know that it is written anywhere, but it has certainly been discussed on infrastructure repeatedly. (A good first step for you would have been to check how other projects are serving their websites. You are certainly not following any standard pattern.) Brett provided a link above, which I haven't yet had time to read. If this is not sufficient to perform the task, if you can give me some pointers on how to accomplish it this will also help. We do want the site content to be the wiki static site so some specific ideas on how to do this will give us some specific action items. It looks like the link is a little out-of-date. It was written before people.apache.org:/www/confluence-exports existed. I believe the standard technique now is to symlink your content from there. Joshua. 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: [jira] Commented: (INFRA-1245) Create new TLP OpenJPA
Thank you thank you thank you. Can you make sure you can edit the people.apache.org /www/ openjpa.apache.org directory (need to be in the openjpa unix group) to facilitate your work later? All the committers should be in the unix openjpa group already but this is part of the migration so it might not be set up yet. Craig On May 25, 2007, at 11:12 AM, Marc Prud'hommeaux wrote: I'll try to look into this sometime this evening (PST). On May 25, 2007, at 11:07 AM, Joshua Slive wrote: On 5/25/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Joshua, I would appreciate some help here. I have no time to troll through all other Apache web sites looking for models. Is there a quick 1-pager on how to symlink the OpenJPA confluence web site to be our www web site? Or another project that does so with a public www/projectnamehere that I can model? Sorry, but your confluence guys need to come up with the procedures yourself. I don't use confluence. I can only tell you what is required to have a reliable, maintainable apache infrastructure. But you can probably use the instructions from http://cwiki.apache.org/CWIKI/ just replacing the ~jefft location with the location under /www/confluence-exports. Joshua. 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: REMOVE
For subscription information, please see http://incubator.apache.org/ openjpa/mail-lists.html Craig On May 24, 2007, at 7:08 AM, Majeed Arni wrote: Regards, Majeed Arni Senior Software Engineer SOA Advance Technology, Development Lab, http://www.ibm.com/webservices/eis. IBM Corporation, 11501 Burnet Road, Mailstop: 9022D004, Austin, TX 78758 email:[EMAIL PROTECTED] | Office:(512) 838-1769 | T/L: 678-1769 | Cell:(512) 296-4065| FAX (512) 838-9666 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: [VOTE] move current release to 1.0.0-SNAPSHOT
Changing my vote to +1 after this discussion. I agree this is the right discussion to have. On May 23, 2007, at 5:41 PM, Patrick Linskey wrote: How do 1.0 and 1.0.0 differ? The way I've done things in the past, the first major release is called 1.0.0, the first patch release 1.0.1, etc. The way I've done things is the first major release is called 1.0, the first patch release is 1.0.1, etc. So we're not too far off. Then, when I say 1.0, what I really mean is the latest code in the 1.0 branch, whatever that is right now. That's a new one on me. But I can see it has merit. When we did Kodo releases in the past, we tried hard to not do new feature development in a maintenance branch. Right. So, following that methodology, once we released 1.0.0, we would make a 1.0 branch, which would periodically have tags on it when we release 1.0.1 etc. As soon as 1.0 was out, all the interesting new cool stuff would then go into the mainline, which would be 1.1.0-SNAPSHOT. (Unless, of course, we had already cut a branch for 1.1 also, in which case the mainline would be 1.2.0-SNAPSHOT, etc.) Ok. I can see that this naming scheme is consistent. And I think we can use this along with Phill's suggestions: Why don't we follow (I believe the SUN standard) convention of using the three digits as in 1.2.3. A change from 1.2.3 to 1.2.4 is a bug fix release no new functionality and fully backward compatible. Backward compatible == user classes built with e.g. 1.1.4 will execute with 1.1.5 but user classes built with 1.1.5 won't necessarily work with 1.1.4. A change from 1.2.3 to 1.3 can have new functionality and bug fixes but is fully backwards compatible. New features can be added but only in a backward compatible way. Finally a change from 1.2.3 to 2.0 is new functionality, bug fixes and no guarantee of backward compatibility Backward compatibility is still a goal but not a requirement. Craig -Patrick On 5/23/07, Craig L Russell [EMAIL PROTECTED] wrote: -1 I like the idea of having our first release out of the incubator be 1.0. Let's drop the trailing .0 and reserve the third digit for patch releases. This brings up the issue of release naming which we've deferred until now. I think we need to decide what we call releases and at what level we support backward compatibility. I'll just emphasize my earlier comments about going through the open JIRA issues and really making sure that we'll address the major functionality, performance, and usability deficiencies. So this will affect the schedule but not the naming of the release. Craig On May 23, 2007, at 12:30 PM, Marc Prud'hommeaux wrote: We recently discussed committing ourselves to the next release being OpenJPA 1.0.0. The general consensus seems to be in favor, so I'm putting it to a vote. +1 Make the current release be 1.0.0-SNAPSHOT, which indicates that the next released version will be 1.0.0 -1 Leave the current release to be 0.9.8-SNAPSHOT 0 Don't care This vote will remain open until 12pm PST on 5/26. I'll start the voting off by recording my vote: +1 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! -- Patrick Linskey 202 669 5907 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: missing getAll(List keys) method?
Hi Daniel, On May 24, 2007, at 11:59 AM, Daniel Lee wrote: Hi Craig, I think findAll() is different. It is a client level API and the getAll() here is for internal fetch from data cache. In the example, when an application issue findAll() for a list of customers. It internally, for each customer with order(s), loads the eager relationship (orders) from data cache if they are already cached by calling map.get(orderId) for each order placed by the customer. It again load the items that are related to each order by calling map.get (itemId) for each item if the relationship to Order is declared as eager. This is potentially a performance bottleneck and findAll() does not avoid this. Seems that this algorithm can be improved to use the broker's findAll mechanism when the instance is not found in the cache. The not-found instances can be found more efficiently than the code currently does. Craig Thanks. Daniel On 5/23/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Daniel, Take a look at the findAll(Collection oids) method of OpenJPAEntityManager. This should do a better job than N get(Object key) methods. Craig On May 23, 2007, at 3:55 PM, Daniel Lee wrote: Do we miss the getAll(List keys) method for data cache? When fetching objects with eager to-many relationships, the code is calling get(Object key) multiple time (one for each object in the relationship). For example, it is doing 1 get() call for each order placed by a customer which we are fetching, that means 100 calls for a customer with 100 orders. The performance can be greatly improved if we have getAll(List keys) methods which returns all orders in one call. This is especially important in a distributed environment. Is there a way (new plug-in) to avoid the multiple-trip for single relationship, or can we implement the code to improve the performance in this area? Many thanks. Daniel 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! 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
Fwd: [CONF] OpenJPA: OpenJPA+Email (page edited)
FYI, these email aliases are not yet active, but should be shortly (Apache time). Craig Begin forwarded message: From: [EMAIL PROTECTED] Date: May 24, 2007 2:46:00 PM PDT To: [EMAIL PROTECTED] Subject: [CONF] OpenJPA: OpenJPA+Email (page edited) Reply-To: open-jpa-dev@incubator.apache.org Page Edited : openjpa : OpenJPA+Email OpenJPA+Email has been edited by Craig Russell (May 24, 2007). (View changes) Content: OpenJPA email [EMAIL PROTECTED] This alias is primarily for the developers on the OpenJPA project. To subscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif To unsubscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif Archives can be found at http://mail-archives.apache.org/mod_mbox/ openjpa-devinline: linkext7.gif [EMAIL PROTECTED] This alias is primarily for users of OpenJPA. To subscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif To unsubscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif Archives can be found at http://mail-archives.apache.org/mod_mbox/ openjpa-usersinline: linkext7.gif [EMAIL PROTECTED] This alias tracks all changes to the OpenJPA svn repository. To subscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif To unsubscribe, send mail to [EMAIL PROTECTED]inline: mail_small.gif Archives can be found at http://mail-archives.apache.org/mod_mbox/ openjpa-commitsinline: linkext7.gifPowered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences 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: Test failures
Same here. Craig On May 24, 2007, at 5:28 PM, Pinaki Poddar wrote: Yes, 'svn clean' was missing. $ svn switch /path/to/new/location $ mvn clean package runs successfully Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 5:48 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Test failures That sounds like a non-clean database or something. What happens with a 'mvn clean' first? All tests are passing on my CI machine. -Patrick On 5/24/07, Pinaki Poddar [EMAIL PROTECTED] wrote: Is it just me, or is integration-test broken? Observed the same since did a 'svn switch' Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 24, 2007 4:07 PM To: open-jpa-dev@incubator.apache.org Subject: Test failures Is it just me, or is integration-test broken? [INFO] - - -- [INFO] Building OpenJPA JPA JDBC [INFO]task-segment: [integration-test] [INFO] - - -- ... Everything is fine until this. Something I'm doing wrong perhaps? Running org.apache.openjpa.persistence.relations.TestLRS 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 1 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 2 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). 0 test INFO [main] openjpa.Runtime - Starting OpenJPA 0.0.0 0 test INFO [main] openjpa.jdbc.JDBC - OpenJPA will now connect to the database to attempt to determine what type of database dictionary to use. To prevent this connection in the future, set your openjpa.jdbc.DBDictionary configuration property to the appropriate value for your database (see the documentation for available values). 1 test INFO [main] openjpa.jdbc.JDBC - Using dictionary class org.apache.openjpa.jdbc.sql.DerbyDictionary (Apache Derby 10.2.2.0 - (485682) ,Apache Derby Embedded JDBC Driver 10.2.2.0 - (485682)). Tests run: 3, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 0.205 sec FAILURE! testEMClear(org.apache.openjpa.persistence.relations.TestLRS) Time elapsed: 0.095 sec FAILURE! junit.framework.AssertionFailedError: expected:3 but was:6 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at junit.framework.Assert.assertEquals(Assert.java:201) at junit.framework.Assert.assertEquals(Assert.java:207) at org.apache.openjpa.persistence.relations.TestLRS.assertLRS (TestLRS.java:92) at org.apache.openjpa.persistence.relations.TestLRS.testEMClear (TestLRS.java:62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at
Fwd: [continuum] BUILD FAILURE: OpenJPA Distribution
We need to fix the continuum builds which check out the incubator/ openjpa stuff. While we're there, how about fixing this? Craig P.S. I don't know where/what/how continuum... Begin forwarded message: From: Wendy Smoak [EMAIL PROTECTED] Date: April 21, 2007 2:35:33 PM PDT To: Craig L Russell [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [continuum] BUILD FAILURE: OpenJPA Distribution On 4/21/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi, Could the vm used to build openjpa be given some more memory to allow the build to go through more often? Is this something the openjpa folks can do ourselves? export MAVEN_OPTS=-Xmx512m (Adjust as necessary. According to [1], JDK 1.5 max heap size defaults to 1/4 the physical memory, and I don't know how much is available to each vm.) [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/gc-ergonomics.html -- Wendy 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: Enable Java 2 Security in EE environment causes Access denied exception
On May 22, 2007, at 7:22 PM, Kevin Sutter wrote: Here's my take (just to generate some discussion)... Right now, it doesn't seem like OpenJPA is ready for Java 2 Security. It's a bug that OpenJPA doesn't use doPrivileged blocks around security-protected APIs. Can you file a JIRA issue with as many of these cases as you can find? They need to be fixed. As Albert has pointed out, there only seems to be two places in the code where doPriv blocks exist. It would seem that any application-managed path that would attempt to access secure operations would require a doPriv block. Right. This may also apply to the container-managed paths, but more than likely, these paths have some type of application-server wrapper around the OpenJPA objects and they could do the proper doPrivs. Doubtful. It would be a bug for trusted code to wrap a call to untrusted code in a doPrivileged block. That would defeat the architecture of the security model. Rather, each component that needs to access secure resources needs to wrap the call in doPrivileged blocks. It would also seem that we would need to provide instructions for proper updating of the policy files (for both the application-managed and container-managed scenarios). Correct. I know we're hitting these type of problems in the WebSphere environment. I would be surprised if other app servers won't be experiencing similar problems if Java 2 security is turned on. We're just trying to figure out the who's responsible for what processing. I've been through this exercise with JDO and put doPrivileged blocks around everything that needed it. It turned out to be about 40 places in the code. Not a big deal. Patrick, were there any discussions on the expert group concerning the relationship between JPA and the Java 2 Security? I asked a number of times for a security audit to be made of the security implications of JPA and it was never taken up. Most of the vendors make extensive use of privileged operations including getting system properties, reflection, and class loader operations and IMHO not enough attention was paid to getting it right. Craig Thanks, Kevin On 5/17/07, Albert Lee [EMAIL PROTECTED] wrote: I ran into the following exception when I enabled Java 2 security in the Java EE environment using openjpa in the WebSphere environment: java.security.AccessControlException: Access denied ( java.lang.RuntimePermission getClassLoader) at java.security.AccessController.checkPermission( AccessController.java :104) at java.lang.SecurityManager.checkPermission (SecurityManager.java:547) at com.ibm.ws.security.core.SecurityManager.checkPermission( SecurityManager.java:189) at java.lang.Thread.getContextClassLoader(Thread.java:490) at org.apache.openjpa.lib.conf.Configurations.findDerivedLoader( Configurations.java:232) at org.apache.openjpa.lib.conf.Configurations.newInstance( Configurations.java:194) at org.apache.openjpa.lib.conf.ObjectValue.newInstance( ObjectValue.java :103) at org.apache.openjpa.lib.conf.PluginValue.instantiate( PluginValue.java :101) at org.apache.openjpa.lib.conf.ObjectValue.instantiate( ObjectValue.java :79) at org.apache.openjpa.conf.OpenJPAConfigurationImpl.getDataCacheManagerI nstance (OpenJPAConfigurationImpl.java:583) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker( AbstractBrokerFactory.java:169) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker( DelegatingBrokerFactory.java:142) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityM anager ( EntityManagerFactoryImpl.java:190) at com.ibm.websphere.ejb3sample.counter.StatelessCounterBean.getTheValue (StatelessCounterBean.java:63) The scenario is a openjpa entity manager factory is injected to a stateless session bean and it is trying to create an EntityManager from the factory. Since the factory is directly injected in the application, the container has no involvment in handling the AccessController.doPrivileged(). Another similiar scenario is Persistence.createEntityManagerFactory() is called from within a stateless session bean, in which a similiar but different security related symptom is surfaced. These tests run successfully when Java 2 security is disabled. A security policy has put in place in the app server to give all permissions to the openjpa jar files in the app server. For experimentation, I add a doPrivilege block in the Configurations.findDerivedLoader where the above exception took place and I was able to by-pass the failure and the doPriv seems to work. However I went into the same exception in different places when getSystemClassLoader() and other privileged operations are used. Questions: 1) How is security being handled in openjpa or JPA in general? 2) What is the philosphy of putting doPrivilege construct around security sensitive code in openjpa? I only find 2
Re: [VOTE] move current release to 1.0.0-SNAPSHOT
-1 I like the idea of having our first release out of the incubator be 1.0. Let's drop the trailing .0 and reserve the third digit for patch releases. This brings up the issue of release naming which we've deferred until now. I think we need to decide what we call releases and at what level we support backward compatibility. I'll just emphasize my earlier comments about going through the open JIRA issues and really making sure that we'll address the major functionality, performance, and usability deficiencies. So this will affect the schedule but not the naming of the release. Craig On May 23, 2007, at 12:30 PM, Marc Prud'hommeaux wrote: We recently discussed committing ourselves to the next release being OpenJPA 1.0.0. The general consensus seems to be in favor, so I'm putting it to a vote. +1 Make the current release be 1.0.0-SNAPSHOT, which indicates that the next released version will be 1.0.0 -1 Leave the current release to be 0.9.8-SNAPSHOT 0 Don't care This vote will remain open until 12pm PST on 5/26. I'll start the voting off by recording my vote: +1 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
Fwd: svn commit: r541098 - in /openjpa/trunk/board: ./ 2007-06.txt
Part of the Apache Way is regular reporting to the board of the activities of each project, including OpenJPA. There will be a file for each month in which we are required to report, and I'll update the information. The Monday before the board meeting (third Wednesday of each month) I'll finalize the report. I've decided to keep this information handy at the trunk level so that all the community members can see what's going on (managing up). I'd encourage all of you to update the file for the next meeting based on information that you would like to share. Tidbits like encounters with customers and other projects, interesting blogs, etc. are welcome. Don't worry about format etc., as I'll clean it up before submitting it. Craig Begin forwarded message: From: [EMAIL PROTECTED] Date: May 23, 2007 3:04:58 PM PDT To: [EMAIL PROTECTED] Subject: svn commit: r541098 - in /openjpa/trunk/board: ./ 2007-06.txt Reply-To: open-jpa-dev@incubator.apache.org Author: clr Date: Wed May 23 15:04:57 2007 New Revision: 541098 URL: http://svn.apache.org/viewvc?view=revrev=541098 Log: Add board report Added: openjpa/trunk/board/ openjpa/trunk/board/2007-06.txt (with props) Added: openjpa/trunk/board/2007-06.txt URL: http://svn.apache.org/viewvc/openjpa/trunk/board/2007-06.txt? view=autorev=541098 == --- openjpa/trunk/board/2007-06.txt (added) +++ openjpa/trunk/board/2007-06.txt Wed May 23 15:04:57 2007 @@ -0,0 +1,25 @@ +2007-06 Status Report for the Apache OpenJPA Project + +Highlights + +In its first month following graduation from the incubator, +OpenJPA has begun work on its first official release, 1.0. + +Community + +Email traffic on the lists continues to grow as more people +discover that the Java EE 5 specification really does allow +pluggable persistence implementations. + +Governance + +Michael Dick was added to the OpenJPA PMC. + +Releases + +Legal + +Projects + +Conferences + Propchange: openjpa/trunk/board/2007-06.txt -- svn:eol-style = native 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: Remove
Hi Majeed, Please refer to this page for email subscription information. http://incubator.apache.org/openjpa/mail-lists.html Regards, Craig On May 23, 2007, at 2:48 PM, Majeed Arni wrote: 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
Ready to move OpenJPA svn repository?
I think we're about ready to move the repository from https:// svn.apache.org/repos/asf/incubator/openjpa/ to https://svn.apache.org/ repos/asf/openjpa/ If you have changes in your local repository that you want to preserve, you will need to do an svn switch to change your local repo to the new location. Any objections to making the switch? Any last minute changes you want to commit? Craig 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: Ready to move OpenJPA svn repository?
Well, having both copies I think would possibly lead to confusion. I think it's cleaner just to move the repo and svn switch relocate when it's done. Craig On May 22, 2007, at 3:26 PM, Phill Moran wrote: Do we want to carry both for a few days to make sure nothing gets broken? We can do a Maven relocate in the dependencies to warn everyone of the move Phill -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: May 22, 2007 6:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Ready to move OpenJPA svn repository? Let's do it. Once it's done, we should immediately do the restructuring of directories that we discussed earlier. -Patrick On 5/22/07, Craig L Russell [EMAIL PROTECTED] wrote: I think we're about ready to move the repository from https:// svn.apache.org/repos/asf/incubator/openjpa/ to https:// svn.apache.org/ repos/asf/openjpa/ If you have changes in your local repository that you want to preserve, you will need to do an svn switch to change your local repo to the new location. Any objections to making the switch? Any last minute changes you want to commit? Craig 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! -- Patrick Linskey 202 669 5907 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: Ready to move OpenJPA svn repository?
Ok, I tried to move the repo but I don't have enough powers yet to do it. I've asked infrastructure to do it but it might take a bit of time for them to get to it. When it does get moved, you will discover upon trying to svn update or svn commit. When the move takes place, you should simply switch your workspace. I haven't verified this, but you should be able to do this: cd directory above openjpa svn switch --relocate openjpa https://svn.apache.org/repos/asf/openjpa/ What this is supposed to do is to replace all occurrences of https:// svn.apache.org/repos/asf/incubator/openjpa with https:// svn.apache.org/repos/asf/openjpa in your .svn metadta files. Craig On May 22, 2007, at 7:03 PM, Kevin Sutter wrote: Agree. On 5/22/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: I agree: let's just do the move now and deal with any breakage as we find it. On May 22, 2007, at 4:47 PM, Craig L Russell wrote: Well, having both copies I think would possibly lead to confusion. I think it's cleaner just to move the repo and svn switch relocate when it's done. Craig On May 22, 2007, at 3:26 PM, Phill Moran wrote: Do we want to carry both for a few days to make sure nothing gets broken? We can do a Maven relocate in the dependencies to warn everyone of the move Phill -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: May 22, 2007 6:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Ready to move OpenJPA svn repository? Let's do it. Once it's done, we should immediately do the restructuring of directories that we discussed earlier. -Patrick On 5/22/07, Craig L Russell [EMAIL PROTECTED] wrote: I think we're about ready to move the repository from https:// svn.apache.org/repos/asf/incubator/openjpa/ to https:// svn.apache.org/ repos/asf/openjpa/ If you have changes in your local repository that you want to preserve, you will need to do an svn switch to change your local repo to the new location. Any objections to making the switch? Any last minute changes you want to commit? Craig 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! -- Patrick Linskey 202 669 5907 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! 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: Ready to move OpenJPA svn repository?
I haven't been successful yet in switching my local workspace. When someone gets it, please send out what you did... Craig On May 22, 2007, at 7:38 PM, Joe Schaefer wrote: Craig L Russell [EMAIL PROTECTED] writes: Ok, I tried to move the repo but I don't have enough powers yet to do it. I've asked infrastructure to do it but it might take a bit of time for them to get to it. Done. [...] cd directory above openjpa svn switch --relocate openjpa https://svn.apache.org/repos/asf/ openjpa/ That may not work exactly. You probably need to do it for each subdir, eg cd trunk; svn switch https://svn.apache.org/repos/asf/openjpa/trunk cd ../branches; svn switch ... ... -- Joe Schaefer 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: Ready to move OpenJPA svn repository?
Worked for me. Craig On May 22, 2007, at 8:10 PM, Marc Prud'hommeaux wrote: Running svn switch https://svn.apache.org/repos/asf/openjpa/trunk; worked for me. On May 22, 2007, at 8:00 PM, Craig L Russell wrote: I haven't been successful yet in switching my local workspace. When someone gets it, please send out what you did... Craig On May 22, 2007, at 7:38 PM, Joe Schaefer wrote: Craig L Russell [EMAIL PROTECTED] writes: Ok, I tried to move the repo but I don't have enough powers yet to do it. I've asked infrastructure to do it but it might take a bit of time for them to get to it. Done. [...] cd directory above openjpa svn switch --relocate openjpa https://svn.apache.org/repos/asf/ openjpa/ That may not work exactly. You probably need to do it for each subdir, eg cd trunk; svn switch https://svn.apache.org/repos/asf/openjpa/trunk cd ../branches; svn switch ... ... -- Joe Schaefer 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! 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: Historical Session
As I've had it explained to me, you would not choose the time in a user-generated or user-visible query. Instead, the user would set the time and associate it with an EntityManager. The time is invisible to normal entity operations, including queries. For each query for a temporal object (the terminology I've heard) the EntityManager would include the appropriate WHERE clauses into the SQL that would select the proper instances based on the time. So a find by primary key, navigation, or query would have the appropriate WHERE clauses generated with no action on the part of the user. In the example below, the A instance doesn't need to worry about which B it refers to, because the B instances corresponding to A's time are also selected automatically, in that both A and B have corresponding temporal WHERE clauses based on the same time. Craig On May 21, 2007, at 3:16 PM, Ricardo Andere de Mello wrote: yes this look something simple, but it is not... see, objects exists in time, so for example, they are not deleted, they are finalized. the worst part are the relationships, because they are historical too... basically you have a start and end date for that object, and the object with end date null is the actual object. everytime you modify an object you clone it, set the end date of the old, and set the start date of the new. imagine now that A points to B. both are historical objects. if B is modified, a new historical object is created. A should point to the new B, not the old one. so you must have a historical id or a historical id object to point at, that is common to all B. []s, gandhi 2007/5/21, Marc Prud'hommeaux [EMAIL PROTECTED]: Something like: select x from Employee x as x was on January 1, 2002 On May 21, 2007, at 11:01 AM, Kevin Sutter wrote: Sorry to show my ignorance, but what are historical objects? Thanks! Kevin On 5/18/07, Ricardo Andere de Mello [EMAIL PROTECTED] wrote: ok, I'm sending this message to netmind list too, so they can answer my next question too: * Maybe this is a silly question, but is it possible to place netmind's beankeeper historical structure between OpenJPA and the database backstore? I dont think *any* serious commercial application can avoid historical objects. I think netmind's beankeeper is a great thing, and JPA is a good standard. Mixing both projects would be very cool. ;-) []s, gandhi 2007/5/18, Marc Prud'hommeaux [EMAIL PROTECTED]: Sadly, no. We don't have any built-in support for historical support at this time, although we have thought for a long time that this would be a great feature to have. You can, of course, do it yourself manually with a bunch of persistent Date fields, but I agree that this is pretty cumbersome to have to manage yourself. On May 18, 2007, at 11:27 AM, Ricardo Andere de Mello wrote: Does OpenJPA have something similar to TopLink's AsOfClause ? I've been working for some time with OJB and Hibernate, and I'm work a lot with historical objects. It really sucks to manage lots of classes to build a historical structure of objects and object relations. Netminds beankeeper does a great job about this, but I'd like to adhere to JPA... Any idea of implementing historical objects AND RELATIONS, inside JPA? -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 -- Ricardo Andere de Mello Presidente do Quilombo Digital 55 (11) 3271-7928 / 55 (11) 9917-7722 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: First post-graduation OpenJPA release
I'll second two things that David mentioned: 1. Release 1.0 first. We have a release that as others have said, passes the JSR 220 TCK and is production-ready. Let's make some noise. Even though we won't have the incubator to officially bless the releases, it will still take some time to get out. And in the middle of the release, we will likely have to deal with the change of repository from incubator to openjpa. (I think Eddie is overly optimistic in thinking that the incubator = tlp process will only take a week). But I don't think we need to wait until it's complete to start the release process. Now, we need a release manager volunteer. 2. Scrub the bugs in JIRA. I think we should go through them and make sure there are no showstoppers for a 1.0 release. 3. Just one more thing. It doesn't really require a JIRA to track, but a JIRA per area might be useful so we don't get in each others' way. The wiki, site, and doc need to all be updated to remove the incubating disclaimer. Craig On May 20, 2007, at 11:14 AM, David Jencks wrote: On May 20, 2007, at 10:25 AM, Patrick Linskey wrote: It sounds like there are a bunch of new things that we'll be doing in this process; maybe we should do a 0.9.8 first to get the various artifacts all sorted out, and then do a 1.0? I think that there will be enough confusion and retries to get an acceptable 1.0 release out with the moved infrastructure that there's no need to complicate the process with an immediate version change. In other words, go for 1.0 now. I do think you should review the jiras a bit before releasing. For instance I'm sure you want to apply the 2nd patch to OPENJPA-148 or undo the first patch since the first patch makes it really easy to create an NPE. thanks david jencks -Patrick On 5/20/07, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: that said, this is the OpenJPA project, and no matter what the state of the infra move, anything that this group does now is independent and disconnected from the incuabtor On May 19, 2007, at 10:15 PM, Eddie O'Neil wrote: +1 -- assuming the code is ready to go, I agree that it's a good idea to go straight to 1.0. +1 as well to waiting until the TLP infrastructure is complete, which could take a week or more to unbrand from the Incubator, move the website content, etc. Eddie On 5/19/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: I personally lean towards just bumping it up to 1.0 and cutting a release as soon as possible after we complete the incubator-TLP process. A release number 1.0 suggests to so many people that a product is not production-ready, and OpenJPA is so mature and in use in so many mission-critical systems that I think we should just bump all the open issues to a 1.0.1 or 1.1 release and get a 1.0 release out in the public. On May 19, 2007, at 4:31 PM, Craig L Russell wrote: Hi, There's no urgency, but I think we should start discussing what our first release should be out of incubation. Let's take a look at the issues in JIRA and decide if we think that we're ready for a 1.0 release. If not, we can cut a 0.9.8 release and make a list of 1.0 bugs/features to follow. Craig 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! -- Patrick Linskey 202 669 5907 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
OpenJPA graduation news
Congratulations to everyone involved in the OpenJPA project. OpenJPA is now an official Apache Top Level Project. The board approved the resolution that we voted on last week. There is a lot of administrivia to be done, and all this will be done over the course of the next several weeks. Among the items that need to be done are creating a new DNS domain (openjpa.apache.org), transferring the svn repository, transferring the email lists, migrating the web site, updating the wiki and jira, closing out the incubation status, and making sure all the committers can access the various resources. Lots to do, and just a few people to do them. Please be patient, as Apache is still a do-it-yourself organization in many respects. Craig Craig Russell DB PMC, OpenJPA PMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
First post-graduation OpenJPA release
Hi, There's no urgency, but I think we should start discussing what our first release should be out of incubation. Let's take a look at the issues in JIRA and decide if we think that we're ready for a 1.0 release. If not, we can cut a 0.9.8 release and make a list of 1.0 bugs/features to follow. Craig 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: OpenJPA graduation news
Hi Patrick, On May 19, 2007, at 3:28 PM, [EMAIL PROTECTED] wrote: Thanks for making this happen, Craig. Thanks, but this really reflects the readiness of the entire OpenJPA team to work together as an Apache project. Is there anything that I can do to help? There are things that only infrastructure can do and I've asked them to do those things. And a very tiny number of things that only I can do as PMC chair. And of course there are some things that lots of people can do, like remove the incubation disclaimers from the various places they exist on the project. So thanks for the offer and as I discover what all needs to be done I'll let you all know things that can be done by volunteers on the project. I think the biggest thing to do now is to decide on our first release out of incubation. I'll start another thread on this subject. Craig -Patrick On 5/19/07, Craig L Russell [EMAIL PROTECTED] wrote: Congratulations to everyone involved in the OpenJPA project. OpenJPA is now an official Apache Top Level Project. The board approved the resolution that we voted on last week. There is a lot of administrivia to be done, and all this will be done over the course of the next several weeks. Among the items that need to be done are creating a new DNS domain (openjpa.apache.org), transferring the svn repository, transferring the email lists, migrating the web site, updating the wiki and jira, closing out the incubation status, and making sure all the committers can access the various resources. Lots to do, and just a few people to do them. Please be patient, as Apache is still a do-it-yourself organization in many respects. Craig Craig Russell DB PMC, OpenJPA PMC [EMAIL PROTECTED] http://db.apache.org/jdo -- Patrick Linskey 202 669 5907 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: [jira] Created: (OPENJPA-242) JCache (JSR 107) support in the OpenJPA DataCache
Hi Marc, Looks like this JSR started in 2001 and hasn't produced a milestone yet. What's going on with it? Some politics? Would some expert advice from some users (e.g. OpenJPA) help any? Craig On May 19, 2007, at 5:03 PM, Marc Prud'hommeaux (JIRA) wrote: JCache (JSR 107) support in the OpenJPA DataCache - Key: OPENJPA-242 URL: https://issues.apache.org/jira/browse/ OPENJPA-242 Project: OpenJPA Issue Type: New Feature Components: datacache Affects Versions: 0.9.7, 0.9.6, 0.9.0 Reporter: Marc Prud'hommeaux Priority: Minor JSR 107 (JCache: http://jcp.org/en/jsr/detail?id=107 ) support would enable OpenJPA to integrate its data cache with supporting products in a transparent way. This would allow us to support the popular EHCache 1.3 and other JSR 107 compliant caching layers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. 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: the pain of post processing bytecode (another beg for a simple reflection/cglib alternative like hibernate)
I think that there are at least three worthy goals here:
1. Help users migrate from Hibernate to OpenJPA.
2. Help users who want the performance advantages of enhancement to
more easily integrate enhancement into their build/deploy environment.
3. Help users who want to get started with OpenJPA and not deal with
enhancement at all (i.e. have a mode in which OpenJPA runs without
enhancement, albeit slower).
Each of these is a separable project that can be discussed and
implemented independently.
Craig
On May 18, 2007, at 6:31 AM, Phill Moran wrote:
Let's also keep in mind that hibernate, although open source, is
not public
standards based. This will drive some traffic towards JPA. Also as
David pointed
out there is some cost to starting with any persistence framework
(or really any
framework) so total plug and play for no time I think is an
unattainable goal.
Phill
-Original Message-
From: David Ezzio [mailto:[EMAIL PROTECTED]
Sent: May 18, 2007 8:07 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: the pain of post processing bytecode (another beg for
a simple
reflection/cglib alternative like hibernate)
Hi Marc,
The goal of drop-in and play functionality is wonderful, but I
doubt that the
modest proposals thus far will achieve it.
Given that the JPA spec specifies only the EJB-3 configuration, I
don't see how
we can achieve drop-in and play compatibility with application
development
environments configured for any arbitrary JPA implementaion.
At one point, I had code examples working with every known
implementation of
JDO. Even after I had a half dozen implementations under my belt,
it still took
a day or two to get the next implementation working with a sample
application of
my own choosing. I'm guessing that the effort required hasn't
changed for JPA
implementations.
Also, I'm incline to doubt that vendors (even open source vendors)
see it as in
their interest to make it easier for users to switch. Reducing
switching costs
to zero is an interesting goal, but I'm not sure how much value is
there.
Perhaps our goal is more modest, just to make it easier for
Hibernate users to
switch to OpenJPA. Since Hibernate is more popular than OpenJPA,
there's some
real value for us in that.
Best wishes,
David
Marc Prud'hommeaux wrote:
On May 17, 2007, at 5:31 PM, David Ezzio wrote:
I think that the issues raised are best solved with tools,
documentation, and examples.
Of course, if one has been coding to Hibernate for years, it's
unlikely that any combination of tools, documentation, and examples
will make OpenJPA easier to use for that person, but that's not
the standard.
Sure it will. If you are using one JPA implementation, be it
Hibernate, Toplink, or anything else, and you want to drop in
OpenJPA to test it out and see what the performance difference is, if
it doesn't work immediately, you are likely to walk away.
I think that easing the process for someone already familiar with JPA
to get started with OpenJPA without having to pour through
documentation about build-time tools or runtime agent flags is a
supremely useful project, especially at this point where we are on
the
brink of graduation and will soon be getting a lot more attention.
Another important point, in my view, is to make sure the tests
run as
well on Windows (without cygwin!) as they do on Linux, Unix, and
OS/X.
For example, using File.separator to construct resource path names
works great on everything but Windows.
This seems orthogonal to the issue of easing OpenJPA's bytecode
enhancement process. If you find cases where we are relying on
hardcoded UNIX paths, these are obviously bugs and should be handled
by creating JIRA issues.
David
Marc Prud'hommeaux wrote:
I think this is a very worthwhile project. James and a few others
excoriated me about this issue over beers after JavaOne last week,
and, while the bruises from their rhetorical assault are still
healing, their observations about the comparative out of the box
ease of use OpenJPA compared to other systems definitely bears
attention.
As Patrick mentioned, we aren't too far away from being able to use
a dynamic subclassing approach.
Another option I've been thinking about recently is that in JDK
1.6,
you can dynamically attach an agent at runtime to your own JVM
(using an implementation-specific mechanism), and using the
provided
Instrumentation, you can redefine existing methods in classes, even
after the classes have already been loaded. While you cannot add or
remove methods or fields, we might be able to re-work our
PCEnhancer
to use a newly-generated inner class and a lookup in some
IdentityHashMap to perform the same function. E.g., instead of our
currently enhanced
class:
public class SomeEntity {
private String someField;
private StateManager stateManager; // generated
public String getSomeField() {
return pcgetSomeField(this);
}
//
Re: Proposed Board Resolution: Graduate OpenJPA as a Top Level Project
Hi Eddie, Thanks to you for your guidance through the incubator. I'll certainly ask you for help during the transition. Craig On May 17, 2007, at 5:44 AM, Eddie O'Neil wrote: Craig-- It went very well -- the Board unanimously passed the resolution to create an OpenJPA TLP with you as the PMC Chair. Congratulations! Have fun out there in the wild. :) The next steps are to make Infra requests to move things (SVN, mailing lists, etc) out of the Incubator to their TLP home. This is also a good time to make any name changes, for example dropping the extra dash from open-jpa-dev. Some details on the next steps are here: http://www.apache.org/dev/project-creation-tasks.html http://www.apache.org/dev/project-creation.html Let me know if / how I can help through this process. Eddie On 5/16/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Eddie, Thanks for being our eyes and ears at the board meeting. How'd it go? Craig On May 14, 2007, at 9:23 AM, Eddie O'Neil wrote: Thanks for taking care of this, Craig. I'll attend the Board meeting Wednesday in case any questions about this come up. Eddie On 5/13/07, Craig L Russell [EMAIL PROTECTED] wrote: FYI, this is the board resolution message as approved by the incubator. The board meeting is coming up next Wednesday. Craig Begin forwarded message: From: Craig L Russell [EMAIL PROTECTED] Date: May 13, 2007 10:56:45 AM PDT To: [EMAIL PROTECTED] Subject: Proposed Board Resolution: Graduate OpenJPA as a Top Level Project The Incubator has voted [5] to request the board approve the establishment of OpenJPA as a Top Level Project. Please see the project vote at [1] and [2] and the incubator vote at [3] and [4]. Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Geir Magnusson Jr. [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200705.mbox/thread [2] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200705.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/thread [4] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/[EMAIL PROTECTED] [5] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/[EMAIL PROTECTED] Craig Russell DB PMC, OpenJPA PPMC [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! Craig Russell
Re: Proposed Board Resolution: Graduate OpenJPA as a Top Level Project
Hi Eddie, Thanks for being our eyes and ears at the board meeting. How'd it go? Craig On May 14, 2007, at 9:23 AM, Eddie O'Neil wrote: Thanks for taking care of this, Craig. I'll attend the Board meeting Wednesday in case any questions about this come up. Eddie On 5/13/07, Craig L Russell [EMAIL PROTECTED] wrote: FYI, this is the board resolution message as approved by the incubator. The board meeting is coming up next Wednesday. Craig Begin forwarded message: From: Craig L Russell [EMAIL PROTECTED] Date: May 13, 2007 10:56:45 AM PDT To: [EMAIL PROTECTED] Subject: Proposed Board Resolution: Graduate OpenJPA as a Top Level Project The Incubator has voted [5] to request the board approve the establishment of OpenJPA as a Top Level Project. Please see the project vote at [1] and [2] and the incubator vote at [3] and [4]. Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Geir Magnusson Jr. [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. [1] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200705.mbox/thread [2] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa- dev/ 200705.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/thread [4] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/[EMAIL PROTECTED] [5] http://mail-archives.apache.org/mod_mbox/incubator-general/ 200705.mbox/[EMAIL PROTECTED] Craig Russell DB PMC, OpenJPA PPMC [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: DB2 support
On May 9, 2007, at 6:09 AM, Michael Dick wrote: OK, now that I found the relevant section in the documentation I understand what William is asking for. What level of testing do we need to do before we can add a new version of DB2 to the list of supported databases? Is just running our unit test bucket sufficient to add a new database to the list or do we need a more formal process? Well, since we're an open source project, the only formal process is what we as a community decide to do. My personal opinion is that if someone runs tests that pass on a database, that's sufficient to say that we support it. Of course, support in an open source project is a matter of interpretation. If someone has a problem, we basically tell them that they should file a JIRA, provide a reproducible test case, and provide a patch licensed to Apache that fixes the issue. One of the committers will review the patch and check it in if they like it. Now, support for a product based on OpenJPA is a completely different matter, and the Apache OpenJPA project doesn't really have an opinion. Craig On 5/9/07, Michael Dick [EMAIL PROTECTED] wrote: Hi William, I have been running OpenJPA against DB2 v9 with no major issues, and I believe others on the forums have been doing so as well. Admittedly this isn't a certification, but it's at least anecdotal evidence that DB2 v9 will work. For KODO I'd have to refer you to BEA's support statement, but I'd be surprised if they did not support DB2 as well. I'm not sure what you mean by cases to run OpenJPA/KODO on DB2. If you're looking for instructions on how to run the OpenJPA unit tests against DB2 I can help you with that. If you'd prefer to try running your own application against DB2 all you need to do is add the appropriate connection properties to persistence.xml : Something like this should work. . . . properties . . . property name=openjpa.ConnectionDriverName value= com.ibm.db2.jcc.DB2Driver / property name=openjpa.ConnectionURL value=jdbc:db2://localhost:5/TEST / property name=openjpa.ConnectionUserName value=db2user / property name=openjpa.ConnectionPassword value=db2password / . . . /properties . . . Regards, Michael DIck On 5/9/07, William Cai [EMAIL PROTECTED] wrote: Hi list, AFAIK, the latest DB2 version is DB2 enterprise server edition V9.1. But but current OpenJDK only supports DB2 UDB v8.1. Do we have any plans to certify DB2 UDB V8.2 and DB2 v9 recently? Or more realistically -- are there any cases to run OpenJPA/KODO on DB2 UDB v8.2 or DB2 v9? Any input is greatly appreciated. Thanks, William Database Name Database Version JDBC Driver Name JDBC Driver Version Apache Derby 10.1.2.1 Apache Derby Embedded JDBC Driver 10.1.2.1 Borland Interbase 7.1.0.202 Interclient 4.5.1 Borland JDataStore 6.0 Borland JDataStore 6.0 DB2 8.1 IBM DB2 JDBC Universal Driver 1.0.581 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: [VOTE] Packaging with maven
+1 Patrick, you and I were writing at the same time. Gotta stop that. ;-) Craig On May 7, 2007, at 9:35 AM, Patrick Linskey wrote: directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ I think you're probably right -- currently, the dir is named 'trunk', for example. looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. Isn't that one too many 'openjpa' tokens? Couldn't it just be http://svn.apache.org/repos/asf/openjpa/trunk/openjpa, instead of http://svn.apache.org/repos/asf/openjpa/trunk/openjpa-all? -Patrick On 5/7/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Patrick raises a good point. Also, we might also be able to just have the openjpa aggregate jar module be in a sub-directory named openjpa without having to rename the parent module's enclosing directory, since I don't think Maven much cares what the name of the directory in which the parent module resides (I doubt it even ever looks at it). I.e., it would be located at http://svn.apache.org/ repos/asf/openjpa/trunk/openjpa/openjpa. How does that sound? On May 7, 2007, at 9:15 AM, Patrick Linskey wrote: I think it makes sense to rename dirs as appropriate. Remember that once we graduate, we'll be moving repositories anyways, so it would seem like a good opportunity to make structural changes. -Patrick On 5/7/07, Michael Dick [EMAIL PROTECTED] wrote: +1 What would the impact be if we renamed openjpa-all to openjpa? We could change our checkout instructions to read svn co http://svn.apache.org/repos/asf/incubator/openjpa/ trunkopenjpa-parent and then the directories match the artifactId's in pom.xml. The only reason I think this is worth doing is to avoid confusion for new developers down the road. It's just one more thing that we have to remember and explain. Maybe there's an impact to changing the directory name that I missed though. -Mike On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa- VERSION.zip . None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/ OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong
[VOTE][RESULT] Graduate OpenJPA from incubation
The vote in the OpenJPA community to graduate from the incubator to a new top level project has completed. The vote thread can be viewed at [1] starting with message [2]. The next step is to prepare a vote for the incubator. +1 votes were recorded from: Craig Russell Patrick Linskey Marc Prud'hommeaux Phill Moran Dain Sundstrom Hans J. Prueller Pinaki Poddar David Jencks Brian McCallister Kevin Sutter Michael Dick Geir Magnusson Jr. Jay D. McHugh Michael Bouschen Eddie O'Neil No -1 or 0 votes were recorded. A couple of personal observations on the vote I very much appreciate the contributions by our Mentors during the process of incubation, and we still would like to have all of you on the new PMC. So if you change your minds, just speak up and we'll be happy to have you back. The discussion regarding the charter of the new project brings up again the importance of communication, both in terms of knowing what people in the community are thinking and if there is an issue, raising it as soon as anyone notices it. [1] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/ 200705.mbox/thread [2] http://mail-archives.apache.org/mod_mbox/incubator-open-jpa-dev/ 200705.mbox/[EMAIL PROTECTED] Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
[DISCUSS] draft Incubator graduation request
Hi, The following is a draft request for the Incubator PMC to graduate OpenJPA to TLP status. The request will be in the form of a VOTE to recommend the board resolution (minor tweaks are being discussed in a parallel thread). Please review and comment. I'll incorporate comments as I receive them, but expect to send the request to the Incubator a few days after getting the last comment, to be sure everyone can comment on the comments. The earliest would be Wednesday 9-May-2007. Craig Dear Incubator, The OpenJPA podling respectfully requests the Incubator to consider its graduation to a Top Level Project. Please vote on recommending the attached draft board resolution. [ ] +1 Recommend to the board to establish Apache OpenJPA [ ] -1 Do not recommend establishing Apache OpenJPA because... Over the past several months the OpenJPA community has grown from a single large donation to a diverse community of contributors and users. OpenJPA meets the technical requirements for diversity, with committers from three and PPMC members from four independent organizations. Committers from other Apache projects have not only used the incubating releases as dependencies in their projects but provided patches to OpenJPA as well. The OpenJPA community prepared and voted out two releases performed by different release managers. The community readily agreed on the bike-shed issues of code formatting and indentation, and there has been no resurrection of these issues. The community had issues with commit-then-review versus review-then-commit and resolved them win-win. Most recently, a public issue regarding the proposed charter of the TLP was resolved. During the process of incubation, the PPMC learned how to govern itself, voting in new committers and PPMC members. Mentors offered invaluable advice and assistance in getting the project set up and organized. The status file for OpenJPA can be found at: http://svn.apache.org/ repos/asf/incubator/openjpa/STATUS The incubator checklist web page for OpenJPA can be found at: http:// incubator.apache.org/projects/openjpa.html Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Packaging with maven
On May 6, 2007, at 7:55 PM, Marc Prud'hommeaux wrote: On May 6, 2007, at 7:40 PM, Patrick Linskey wrote: +1 to the change. What do you think about changing dir names so that openjpa-all becomes openjpa-dist or something? Do you mean changing openjpa-project (which is the distribution) to openjpa-dist? We could, although it wouldn't impact the artifact names. I think the important thing is the artifact names. Once we agree on the artifact names, we can choose to rename the directories to suit. Craig -Patrick On 5/6/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Poking around the ActiveMQ pom.xml files, I notice that you can have a different artifactId than the module name (i.e., directory) you are in. I hadn't known you could do this. Currently, our artifacts name are: trunk/pom.xml: openjpa trunk/openjpa-all/pom.xml: openjpa-all trunk/openjpa-project/pom.xml: openjpa-project We could change these to: trunk/pom.xml: openjpa-parent trunk/openjpa-all/pom.xml: openjpa trunk/openjpa-project/pom.xml: apache-openjpa I've tested this out, and it results in the openjpa aggregate jar being named openjpa-VERSION.jar, the dependency being simply named openjpa, and the assembly is named apache-openjpa-VERSION.zip. None of the directories needed to be renamed. I've attached the patch that does this to https://issues.apache.org/jira/browse/OPENJPA-194 Since this will mess up people who currently have maven dependencies on OpenJPA (i.e., people who depend on openjpa-all will now need to depend on openjpa), we should probably get this hammered out before leaving incubation. So I've gone ahead and turned the [DISCUSS] into a [VOTE] to see if we should go ahead and do this. A vote of +1 means we should do the renaming, -1 means we should not, and 0 means don't care. The vote will remain open until Wednesday May 9th at 23:59 GMT. On May 4, 2007, at 6:55 AM, Michael Dick wrote: Some comments below On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. +1 But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. +1 Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. I would like to change this too. I did a little experimenting and it looks like the dependencies aren't needed in openjpa-all, but they are needed for openjpa-project (to populate the lib directory). Moving the dependencies into openjpa-project should be safe. We're also going to need to change the deploy logic to strip out the -project suffix from the zip files. We've talked about it before when I was releasing 0.9.7 (and before that when Marc was working on 0.9.6), but I haven't had time to look into it. It should be fairly easy to make the change. Thoughts? Craig 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! -Michael Dick -- Patrick Linskey 202 669 5907 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: IntelliJ IDEA plugin
Hi Patrick, Could you get IJ to open-source the required interfaces needed to compile with? That would be the best option if you wanted to add it to the OpenJPA project. Craig On May 4, 2007, at 4:02 PM, Patrick Linskey wrote: Hi, Earlier this week, I wrote a (very) basic OpenJPA / IntelliJ plugin. It automatically runs the enhancer on persistent types after compilation completes, for any persistence units that don't have a persistence provider declared or that declare OpenJPA as their persistence provider. Clearly, I'd like to make this available for IntelliJ users. Does anyone on this list have any experience with registering, deploying, and maintaining plugins via JetBrains' registry? Also, currently, the plugin includes the OpenJPA jars; I'd prefer if it depended on picking up the jars from the module's classpath, for a bunch of reasons. Does anyone have any experience with writing plugins that use classes defined in the module classpath? Finally, in order to build the sources, certain IntelliJ classes need to be in the classpath. Does anyone know of any Apache precedents for dealing with this type of situation? -Patrick -- Patrick Linskey 202 669 5907 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
[ACTION] Mail aliases
This message is for committers. When conducting official Apache business (e.g. votes), use of your Apache email address is optional. However, to avoid delays, please register your non-Apache email addresses at https://svn.apache.org/ repos/private/committers/MailAlias.txt. Thanks, Craig Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
[DISCUSS] Packaging with maven
I'd like reopen the discussion on how to package and name our artifacts. I think the current setup could be improved, to give a better experience for users who might not be using maven for dependency management. It's easy for us to change now before graduation because once we graduate, people will need to update their dependencies anyway so there are no backward compatibility issues. The name of the single jar that has all of the openjpa stuff in it except for the documentation and examples is currently called openjpa- all. This name is confusing because unless they RTFM, people don't really know that it's not all the code you need, just all the jpa code. So I'd like to call this artifact openjpa. But we already have a project with that name, and that project builds the distributions. So I'd rename the current openjpa to openjpa-dist. Its ultimate destination in the Apache mirror structure is under www.apache.org/dist/openjpa once we graduate, so having dist in the project name helps understanding that this project builds the artifacts that go into dist. Separate from the artifacts that are published via maven. Finally, the openjpa-all jar includes its subcomponents as dependencies. I think this is wrong, since you end up with a class path with openjpa-all.jar as well as openjpa-kernel.jar and all the others. Thoughts? Craig 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
Fwd: [VOTE] Graduate from Incubation
It's not too late to vote. Everyone in the community is encouraged to review the material, provide any comments, and vote. Craig Begin forwarded message: From: Craig L Russell [EMAIL PROTECTED] Date: May 3, 2007 7:22:05 AM PDT To: open-jpa-dev@incubator.apache.org Subject: [VOTE] Graduate from Incubation Reply-To: open-jpa-dev@incubator.apache.org This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Graduate from Incubation
The vote closes May 6. Standard 3 day period. I should have put this in the original email. Craig On May 4, 2007, at 5:59 AM, Eddie O'Neil wrote: Hi, Craig. Apologies for not having reviewed this yet; I've been traveling this week and without much access to e-mail. When does this vote close? Thanks. Eddie On 5/4/07, Craig L Russell [EMAIL PROTECTED] wrote: It's not too late to vote. Everyone in the community is encouraged to review the material, provide any comments, and vote. Craig Begin forwarded message: From: Craig L Russell [EMAIL PROTECTED] Date: May 3, 2007 7:22:05 AM PDT To: open-jpa-dev@incubator.apache.org Subject: [VOTE] Graduate from Incubation Reply-To: open-jpa-dev@incubator.apache.org This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Graduate from Incubation
Hi Phill, My sense of this community is that they don't want to be restricted in the space of API implementations that make sense for their pluggable persistence engine. I would like to hear from other community members on this subject. If you feel that you want to change your vote and have the community vote on adding restrictions of their charter in the board resolution, please do follow up. I'm happy to call another vote on this specific subject prior to asking for Incubator approval to graduate. Just ask. On May 4, 2007, at 12:16 PM, Phill Moran wrote: Without getting any nastier let me explain. I don't see any evidence of nasty. I see a discontinuity in calling the project OpenJPA if in reality the project implements JDO and so forth. The project is clearly focused now on building a solid implementation of the JPA API. But I don't see why we would want to require a different community to be formed to build a different interface. There are people in this community with broader interests than JPA. And I'm also concerned that since we are trying to build a diverse community, we want to be as inclusive as makes sense. Narrowing the board charter won't help in community building. Look at Cayenne. No one would tell them not to implement a different API. Their board charter is as broad as ours. If we can separate the engine from the API and make the API pluggable/selectable and the project is planning on implementing other APIs then a name change seems reasonable as it would not be representative of what we are providing. There are good marketing reasons for calling the project Apache OpenJPA. But please look at the history of persistence APIs and projects. Which API will be dominant in 3 years? Still Hibernate? And what if we want to experiment with a Groovy subset/superset of JPA that might be more appropriate for scripting? If we are to go down this path then I would further suggest we separate the engine and implementing APIS into separate jars/packages as it is wasteful Already been done. Please look at the package structure. Nothing wasted. And if we did ship an SDO implementation it could ship with its own dependencies excluding JPA or including JPA interface. We already publish our artifacts separately via maven in addition to publishing a fat jar and binary and source distributions. and potentially dangerous to package all implementations together. Dangerous? Interesting theory. That is all this little piece of the community has to say. I do appreciate your bringing up this issue to make sure we have consensus. Craig Phill -Original Message- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: May 4, 2007 2:50 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] Graduate from Incubation On May 4, 2007, at 10:50 AM, Phill Moran wrote: Would we then not have to change the overall name from JPA to openPersistence or some such? That would suck. I see no reason we would have to change the name. It is a choice of the community. Why not let another project lift out the engine and adapt JDO/SDO/ETC and maybe we remerge the projects later. I would hate to see a fork. Maybe this idea works if we can fully separate the API from the persistence engine as it does not make sense to go into production with several unused API being deployed. It is already separated. -dain Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
[VOTE] Graduate from Incubation
This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [EMAIL PROTECTED] http://db.apache.org/jdo smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Graduate from Incubation
+1 Craig On May 3, 2007, at 7:22 AM, Craig L Russell wrote: This vote is to send the attached draft board resolution to the incubator for the purpose of graduation from the incubator to the Apache OpenJPA project. +1 We're ready; let's graduate 0 Don't care -1 Let's wait Establish the Apache OpenJPA project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project, to be known as Apache OpenJPA, related to the implementation of object persistence, including, but not limited to, Java Persistence API, for distribution at no charge to the public; NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the OpenJPA PMC be and hereby is charged with the creation and maintenance of Apache OpenJPA; and be it further RESOLVED, that the office of Vice President, Apache OpenJPA be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the OpenJPA PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache OpenJPA PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the OpenJPA PMC: Eddie O'Neil[EMAIL PROTECTED] Geir Magnusson Jr. [EMAIL PROTECTED] Brian McCallister [EMAIL PROTECTED] Patrick Linskey [EMAIL PROTECTED] Craig Russell [EMAIL PROTECTED] Kevin Sutter[EMAIL PROTECTED] Abe White [EMAIL PROTECTED] Marc Prud'hommeaux [EMAIL PROTECTED] NOW, THEREFORE, BE IT FURTHER RESOLVED, that Craig Russell be appointed to the office of Vice President, Apache OpenJPA, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial OpenJPA PMC be and hereby is tasked with the migration and rationalization of the Apache Incubator OpenJPA podling; and be it further RESOLVED, that all responsibility pertaining to the Apache Incubator OpenJPA podling and encumbered upon the Apache Incubator PMC are hereafter discharged. Craig Russell DB PMC, OpenJPA PPMC [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: [CONF] OpenJPA: Powered By (page edited)
Hi Kevin, I understand your concern. We could sort by last letter. But you'd still be underneath bea, ode, and openejb. ;-) Also, you have such a teeny tiny little graphic it gets totally lost underneath the camel. How about making the Websphere graphic ten times bigger? Or coming up with a cooler graphic entirely? Craig On May 2, 2007, at 6:57 AM, Kevin Sutter wrote: The ordering of the products on this page has bothered me for quite some time -- especially since WebSphere is always listed last. :-) Alphabetically is better (as James just did), but still not great. I have seen web sites that will randomly sort entries on a page such as this so that every time that someone views the page, they get a different view of the products. I've looked at the wiki editing capabilities of confluence, but haven't found this feature. Does anybody know of a means of doing this on our wiki? Thanks, Kevin On 5/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Page Edited : openjpahttp://cwiki.apache.org/confluence/ display/openjpa: Powered By http://cwiki.apache.org/confluence/display/openjpa/Powered+By Powered By http://cwiki.apache.org/confluence/display/openjpa/ Powered+Byhas been edited by James Strachan http://cwiki.apache.org/confluence/display/%7Ejstrachan (May 02, 2007). (View changes)http://cwiki.apache.org/confluence/pages/ diffpagesbyversion.action? pageId=23631originalVersion=9revisedVersion=10 Content: This page list products and companies that are currently using OpenJPA. BEA Kodo http://bea.com/kodo/: Kodo is the project from which the OpenJPA source code was derived. Kodo is now, in turn, based on the Apache OpenJPA project and is in production use in hundreds of mission- critical applications around the world. OpenJPA is included as part of Kodo 4.1 and higher Spring http://www.springframework.org: The popular Spring framework is the leading full-stack Java/J2EE application framework, delivering significant benefits for many projects, reducing development effort and costs while improving test coverage and quality. OpenJPA is shipped as part of Spring 2.0.1 Geronimo http:// geronimo.apache.org/: The Geronimo project is a free software application server developed by the Apache Software Foundation and distributed under the Apache license. The goal of the Geronimo project is to produce a server runtime framework that pulls together the best Open Source alternatives to create runtimes that meet the needs of developers and system administrators. OpenJPA is shipped as part of Geronimo 1.2 beta and 2.0-m1. OpenEJBhttp:// incubator.apache.org/openejb/: OpenEJB is an open source, modular, configurable, and extendable EJB Container System and EJB Server. OpenJPA is included with OpenEJB version 3.0 and later. Apache Ode Ode http://incubator.apache.org/ode/: Ode (Orchestration Director Engine) is an Apache incubated project to develop an open-source, Apache-licensed, implementation of the WS-BPEL 1.1 and WS-BPEL 2.0 (draft) specifications. Ode is a choreography engine allowing you to develop processes to call services in a well-defined manner. OpenJPA is included with Ode version 2.0 and later. ActiveMQhttp:// activemq.apache.org: Apache ActiveMQ is the most popular and powerful open source Message Broker which supports many Cross Language Clients and Protocols and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. OpenJPA is included with ActiveMQ version 4.2 and later. WebSphere Application Server Version 6.1 Feature Pack for EJB 3 Alphahttps://www14.software.ibm.com/ iwm/web/cc/earlyprograms/websphere/was61ejb3/: The Alpha release of the IBM WebSphere Application Server Feature Pack for EJB 3.0 contains a preliminary implementation of the Enterprise JavaBeans Version 3.0 specification, commonly known as EJB3. Associated with the Enterprise JavaBeans Version 3.0 specification is the Java Persistence API specification, commonly known as JPA. The Alpha JPA implementation is powered by OpenJPA. Powered by Atlassian Confluencehttp://www.atlassian.com/ software/confluence/default.jsp?clicked=footer(Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature requesthttp:// jira.atlassian.com/secure/BrowseProject.jspa?id=10470 Unsubscribe or edit your notifications preferenceshttp:// cwiki.apache.org/confluence/users/viewnotifications.action 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: ApacheCon Europe
I'll be there as well. Craig On Apr 25, 2007, at 12:05 AM, Patrick Linskey wrote: Hey, Is anyone else going to be at ApacheCon next week? Marc Prud'hommeaux and I will both be there. -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. 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. 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: Possible problem with ddl with only a jta-datasource and sequences
On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
David-
Does this seem like a reasonable explanation?
That sounds right to me.
Note that if we ever update OpenJPA to depend solely on the
TransactionSynchronizationRegistry, then we won't be able to do
things like suspending the transactions and resuming it later with
the jta-datasource.
That's why we have two datasources for an EMF. One is the
transactional datasource that gives you connections automatically
enlisted in your transactional EM; the other gives you connections
that are never enlisted and can be used for nontransactional queries,
nontransactional sequences etc. The TSR is only of use for the
enlisted datasource/connection.
Craig
On Apr 24, 2007, at 10:52 AM, David Jencks wrote:
Using derby, jta transactions (in geronimo), a table sequence,
autocreation of tables, and only a jta-datasource, I get errors
complaining that the sequence table doesn't exist.
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
Table/View 'OPENJPASEQ' does not exist. {SELECT SEQUENCE_VALUE
FROM OPENJPASEQ WHERE ID = ? FOR UPDATE WITH RR} [code=2,
state=42X05]
If I supply a non-jta-datasource everything works fine.
My current theory about why this is happening is that the ddl to
create all the tables is executed in a connection from the jta-
datasource that's enrolled in a jta transaction. Then we go to
get an id from the sequence, the jta transaction is suspended, and
a new tx is started, in which the ddl is not visible since the jta
tx wasn't committed. (apparently ddl in derby is transactional)
Does this seem like a reasonable explanation?
I'm going to look for a way to run the ddl inside a separate
transaction that can be committed, the same as how sequences work
without a non-jta-datasource. One way to do this would be to
package the work up in a Runnable and execute it in an
appropriate transactional environment. It might be easier to
understand if the sequence code had a similar implementation.
thanks
david jencks
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: Cascade question (ver 0.96)
I think maybe the issue is a simple usage issue. If you already have a persistent StoreType instance, and you store a reference to it in a new Store instance, then when you persist the Store, the StoreType instance is simply used to provide a foreign key in the database. And if you have a detached Store instance and set the relationship to a detached StoreType instance, when you merge, the StoreType is again used as a reference to provide the foreign key. Are you using a persistent or detached StoreType as the reference in your Store? Because if you're using a new StoreType instance and there is already an instance of StoreType in the database, you will get an error. Craig On Apr 24, 2007, at 11:53 AM, Phill Moran wrote: That is my concern I should only have one copy of a storeType for many Store entries. So if I add a record on the one side (Store) of a one-to- many relationship and have a relation set to an existing Many side (StoreType) I don't want a new Many side record created as this would be a duplicate. It seems unless I specify a cascade.Merge/Persist on the relationship field I cannot persist a new Store with a relationship to a StoreType record even though the StoreType record exists and does not need merging/persisting. What I am looking to do is only persist data on the one side of the relationship and never the Many. Make sense or just crazy coding? Phill -Original Message- From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: April 24, 2007 2:23 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Cascade question (ver 0.96) Phill- The behaviour I am looking for is simply persist the relation (i.e. the link field) If you specify cascade=MERGE on the StoreType relation field, and you merge a Store instance for which the StoreType relation doesn't already exists, does it not persist the field as if it were new? That's the behavior I would expect... On Apr 23, 2007, at 9:55 PM, Phill Moran wrote: Here is a scenario that shows odd behaviour, I want to see if it is expected or not. The docs are not clear on it If I have a many to one relationship for objects Store to Store Type and I create a new Store and assign it to an existing Store type does this relationship have to have cascasdeType.persist set when I issue a merge on the new Store? I had recently removed this as I thought I did not want to create a duplicate Store Type whenever I added a new Store. It seems OpenJPA throws the attached exception when I only have CascadeType.Refresh set. Alternatively, this could just be a poorly worded exception/ documentation meaning OpenJPA would check for the existence of this Store Type and not actually persist it if it exists. The behaviour I am looking for is simply persist the relation (i.e. the link field) Thanks, Phill 4|false|0.9.6-incubating org.apache.openjpa.persistence.ArgumentException: Encountered new object ca.BidSpec.emall.categories.Category-105603b-508b-9c6-00f4-4031ba642 9 e3:0 in persistent field ca.BidSpec.emall.stores.Store.type of managed object [EMAIL PROTECTED] during attach. However, this field does not allow cascade attach. You cannot attach a reference to a new object without cascading. FailedObject: ca.BidSpec.emall.categories.Category-105603b-508b-9c6-00f4-4031ba6429 e 3:0 at org.apache.openjpa.kernel.AttachStrategy.getReference (AttachStrategy.java:272) at org.apache.openjpa.kernel.AttachStrategy.attachField (AttachStrategy.java:189) at org.apache.openjpa.kernel.VersionAttachStrategy.attach (VersionAttachStrategy.jav a:130) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java: 236) at org.apache.openjpa.kernel.AttachManager.attach (AttachManager.java:97) at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3124) at org.apache.openjpa.kernel.DelegatingBroker.attach (DelegatingBroker.java:1120) at org.apache.openjpa.persistence.EntityManagerImpl.merge (EntityManagerImpl.java:59 1) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.jav a:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.orm.jpa.ExtendedEntityManagerCreator $ExtendedEntityManagerIn vocationHandler.invoke(ExtendedEntityManagerCreator.java:283) at $Proxy37.merge(Unknown Source) at ca.BidSpec.emall.persistence.JPAPersistenceFactory.merge (JPAPersistenceFactory.j ava:95) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.jav a:25)
Re: Artifact names
+1 to all that. What JDO does is publish the non-maven artifacts to the dist/db directory (JDO is a db sub-project) and there is a script that allows us to use the mirrors to let folks get the binary or source download. And we publish the maven artifacts so that a user can just write a pom and five lines of code later maven will download the dependency tree. Sweet. Craig On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote: While in incubation, the best place for non-Maven downloads is here: http://people.apache.org/dist/incubator/ Once out of incubation, the right place is here: http://www.apache.org/dist/ which ties an artifact into the mirroring system. Then, there's a particular way to format the project's download page in order to list all of the mirrors as download options for that artifact a la: http://struts.apache.org/download.cgi Eddie On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote: On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote: I don't think you want the tarball in maven. Personally I would not look for it there or go searching my local repo to open and get examples, docs etc. Can we keep the tarball on OpenJPA and the minimal compile an execution jar on Maven. Keep in mind that this jar is replicated on maven, corp repo then local repo - a lot of wasted space if not absolutely necessary. Phill I agree, if we put the tarball in a different location then we should remove it from the maven repository at the same time. It shouldn't be too tricky to separate the tarball generation from the normal build processing (in which case maven won't deploy the tarball). Assuming this is the right way to go, where would be put the tarball? -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 24, 2007 10:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Artifact names Personally, I think both are valuable as they serve different needs for different development environments. I agree completely. Just wondering if we should be publishing the tarball via mvn. -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: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 7:41 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names It's a fair question -- if you want people to be able to sync dependencies from Maven directly into their projects via pom.xml references, then the Maven repository is the way to go. If you want to distribute a single package that contains everything (binaries, docs, samples, etc) needed to get started with OpenJPA and doesn't require the user to use the Maven project model, then the source / binary zip archives are the way to go. Personally, I think both are valuable as they serve different needs for different development environments. Eddie On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: On Apr 24, 2007, at 7:27 PM, Patrick Linskey wrote: Hmm. I wonder if we're really using Maven repositories correctly. Do we need our dist to be in Maven at all? We don't need to. It was just easy to set up that way. I do think that we should have something that's easy to depend on that pulls in the openjpa-persistence-jdbc module, without making people have to know about that level of modularity detail. Why can't they just depend on openjpa-all? That brings everything in... -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: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 7:05 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names
Re: Artifact names
On Apr 25, 2007, at 11:25 AM, Marc Prud'hommeaux wrote: Does anyone happen to know if there is a way to override the repository part of the distributionManagement section of the pom.xml? If we were able to do that, we could keep the individual jar artifacts deployed to the http://people.apache.org/repo/m2- snapshot-repository/org/apache/openjpa/ (so people can reference the individual artifacts as usual), but upload the artifacts from the openjpa-project sub-pom to a separate location? On Apr 25, 2007, at 10:29 AM, Craig L Russell wrote: +1 to all that. What JDO does is publish the non-maven artifacts to the dist/db directory (JDO is a db sub-project) and there is a script that allows us to use the mirrors to let folks get the binary or source download. And we publish the maven artifacts so that a user can just write a pom and five lines of code later maven will download the dependency tree. Sweet. Craig On Apr 25, 2007, at 7:07 AM, Eddie O'Neil wrote: While in incubation, the best place for non-Maven downloads is here: http://people.apache.org/dist/incubator/ Once out of incubation, the right place is here: http://www.apache.org/dist/ which ties an artifact into the mirroring system. Then, there's a particular way to format the project's download page in order to list all of the mirrors as download options for that artifact a la: http://struts.apache.org/download.cgi Eddie On 4/25/07, Michael Dick [EMAIL PROTECTED] wrote: On 4/24/07, Phill Moran [EMAIL PROTECTED] wrote: I don't think you want the tarball in maven. Personally I would not look for it there or go searching my local repo to open and get examples, docs etc. Can we keep the tarball on OpenJPA and the minimal compile an execution jar on Maven. Keep in mind that this jar is replicated on maven, corp repo then local repo - a lot of wasted space if not absolutely necessary. Phill I agree, if we put the tarball in a different location then we should remove it from the maven repository at the same time. It shouldn't be too tricky to separate the tarball generation from the normal build processing (in which case maven won't deploy the tarball). Assuming this is the right way to go, where would be put the tarball? -Original Message- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: April 24, 2007 10:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: Artifact names Personally, I think both are valuable as they serve different needs for different development environments. I agree completely. Just wondering if we should be publishing the tarball via mvn. -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: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 24, 2007 7:41 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Artifact names It's a fair question -- if you want people to be able to sync dependencies from Maven directly into their projects via pom.xml references, then the Maven repository is the way to go. If you want to distribute a single package that contains everything (binaries, docs, samples, etc) needed to get started with OpenJPA and doesn't require the user to use the Maven project model, then the source / binary zip archives are the way to go. Personally, I think both are valuable as they serve different needs for different development environments. Eddie On 4/24/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: On Apr 24, 2007, at 7:27 PM, Patrick Linskey wrote: Hmm. I wonder if we're really using Maven repositories correctly. Do we need our dist to be in Maven at all? We don't need to. It was just easy to set up that way. I do think that we should have something that's easy to depend on that pulls in the openjpa-persistence-jdbc module, without making people have to know about that level of modularity detail. Why can't they just depend on openjpa-all? That brings everything in... -Patrick -- Patrick Linskey BEA Systems, Inc. ___ _ __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its
Re: Possible problem with ddl with only a jta-datasource and sequences
Hi Partick,
On Apr 25, 2007, at 11:41 AM, Patrick Linskey wrote:
That's why we have two datasources for an EMF. One is the
transactional datasource that gives you connections
automatically enlisted in your transactional EM; the other
gives you connections that are never enlisted and can be used
for nontransactional queries, nontransactional sequences etc.
The TSR is only of use for the enlisted datasource/connection.
That's one approach for out-of-band work. But, there are other ways to
do such work also, without requiring multiple datasources. For
example,
suspending the current tx, starting a new one, doing the work,
committing, and resuming the old one is a workable solution, if you
have
access to the tx.
My comment was that the two-datasource approach works for all
configurations that I know of, and doesn't depend on the existence of
mutliple non-standardized interfaces by which the transaction service
providers have granted grudging access to their transaction control
mechanism.
There was agreement with TSR on the basic functionality that all
transaction service providers would support. Some vendors pushed back
when we tried to expand the functionality.
If everyone has extra functionality why is it so hard to come to a
common set of features? There's no intrinsic value in one app server
giving access via Proprietary Interface 1 and another app server
giving the same access via Proprietary Interface 2.
What we were able to get with TSR interface was agreement as to how
to deal with transaction-enlisted connections. Perhaps we need to go
back (Umbrella JSR for Java EE 6) and make a bigger fuss over the
additional needed functionality.
Craig
-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, April 25, 2007 10:05 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: Possible problem with ddl with only a
jta-datasource and sequences
On Apr 24, 2007, at 11:38 AM, Marc Prud'hommeaux wrote:
David-
Does this seem like a reasonable explanation?
That sounds right to me.
Note that if we ever update OpenJPA to depend solely on the
TransactionSynchronizationRegistry, then we won't be able
to do things
like suspending the transactions and resuming it later with the
jta-datasource.
That's why we have two datasources for an EMF. One is the
transactional datasource that gives you connections
automatically enlisted in your transactional EM; the other
gives you connections that are never enlisted and can be used
for nontransactional queries, nontransactional sequences etc.
The TSR is only of use for the enlisted datasource/connection.
Craig
On Apr 24, 2007, at 10:52 AM, David Jencks wrote:
Using derby, jta transactions (in geronimo), a table sequence,
autocreation of tables, and only a jta-datasource, I get errors
complaining that the sequence table doesn't exist.
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
Table/View 'OPENJPASEQ' does not exist. {SELECT
SEQUENCE_VALUE FROM
OPENJPASEQ WHERE ID = ? FOR UPDATE WITH RR} [code=2,
state=42X05]
If I supply a non-jta-datasource everything works fine.
My current theory about why this is happening is that the ddl to
create all the tables is executed in a connection from the jta-
datasource that's enrolled in a jta transaction. Then we
go to get
an id from the sequence, the jta transaction is suspended,
and a new
tx is started, in which the ddl is not visible since the jta tx
wasn't committed. (apparently ddl in derby is transactional)
Does this seem like a reasonable explanation?
I'm going to look for a way to run the ddl inside a separate
transaction that can be committed, the same as how sequences work
without a non-jta-datasource. One way to do this would be to
package the work up in a Runnable and execute it in an
appropriate transactional environment. It might be easier to
understand if the sequence code had a similar implementation.
thanks
david jencks
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!
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
Re: More questions on runtime schema generation
The general solution to this problem lies in a crisper definition of classloader domains in the app server. IIUC, each app server has its own policies in terms of where various components get loaded and when. I think we need to engage the server spec team on this, otherwise we will end up chasing multiple incompatible class loader strategies, all of which turn out to be spec compliant. And for a first cut at reasonable we might ask the Spring folks how they handle this. Craig On Apr 25, 2007, at 12:26 PM, Patrick Linskey wrote: However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? It is. Of course, there is no standard way to scan classloaders. The best I know of is to do: cls.getProtectionDomain().getCodeSource().getLocation() and then scan from that URL. Of course, this assumes that a) you have a class (not a ClassLoader), b) you have security privileges to get the protection domain, and b) the location is parsable and accessible. Is there some other way that you know of to scan a ClassLoader? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? It does. -- 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: David Jencks [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 12:18 PM To: open-jpa-dev@incubator.apache.org Subject: More questions on runtime schema generation I'm working on modifications so that ddl can operate in a separate transaction on a connection from the jta ds and I would like to have a complete scan and enhancement as soon as possible when the EMF is first accessed. I have this working when the classes are listed explicitly in the persistence.xml but not when they aren't. It looks like the relevant code is AbstractCFMetaDataFactory getPersistentTypeNames if (names.isEmpty() devpath) scan(new ClasspathMetaDataIterator(null, newMetaDataFilter()), newClassArgParser(), names, false, null); However IIUC this dissects the system property java.class.path and only parses stuff on that. This might be reasonable for a command line tool (although I have some doubts) but it seems to me that for any other situation a scan of the provided classloader would be more appropriate. Is this reasonable? Also, I would like to suggest a flag in the openjpa.jdbc.SynchronizeMappings=buildSchema(...) stuff to turn on this eager scanning I'm trying to implement. Does this seem reasonable? thanks david jencks 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. 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: Open JPA error-Could not locate metadata for the class using alias
Hi tbee,
I've only seen bits and pieces of this issue scattered through a
dozen emails. I understand vaguely that you're trying to separate the
persistent field definition from the behavior, but can't really
understand how you're trying to do it.
Would it be possible for you to post a complete (simple) example that
shows what you are trying to do, including both the classes and the
database schema, for both sides of the relationship.
Thanks,
Craig
On Apr 24, 2007, at 9:21 AM, Marina Vatkina wrote:
tbee wrote:
Marina Vatkina wrote:
I didn't suggest to remove the existing @Entity annotation - what I
suggested was to change the @MappedSuperclass to be an @Entity,
*and* make it
*abstract*.
The latter will mean that you'll never get its instances back.
I've tested this, but OpenJPA still has the same error:
org.apache.openjpa.persistence.ArgumentException: Could not locate
metadata
for the class using alias Article. Registered alias mappings:
{Article=null}
As a comparison, Toplink does not accept this approach at all
(@Entity
extends @Entity). It requires the superclass to be
MappedSuperclass (@Entity
extends @MappedSuperclass).
This is close to impossible as there are probably CTS tests that
use an @Entity
that extends another @Entity. Are you using JPA in an EE 5
container? Otherwise you need to list all antities and mapped
superclasses in your persistence.xml.
-marina
So unforntunately this approach seems to be a dead end.
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
[DISCUSS] OpenJPA Graduation
OpenJPA has done a great job of forming a diverse community around a great code base whose IP has been reviewed and approved for release, and we're now a well-functioning, project in the incubator. So we are now at the stage when we should think about when and how to leave the incubator and graduate to the larger Apache community. The document at [1] describes readiness to graduate. There are two courses for graduating projects: to become an independent Apache TLP or to join an existing TLP as a sub-project. I believe that OpenJPA should become its own TLP for a few reasons: the community is already very diverse and has established a good working style; and there is no existing TLP upon which OpenJPA depends. There is some synergy with the DB project but no dependency relationship. As a TLP, OpenJPA would operate independent from other TLPs and be responsible to the Apache board. As a TLP, the OpenJPA community would decide on offering committerships to the project, and what and when to release, subject to the regulations of the ASF. So what does everyone think? Craig [1] http://incubator.apache.org/incubation/ Process_Description.html#Graduation 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: [DISCUSS] required vs. optional dependencies
I agree that it's nice to have an out-of-the-box database shipped with our distribution. Once Java SE 6 is universal, we can revisit the decision, since Java SE 6 distributes Java DB (a renamed Derby distribution). Craig On Apr 23, 2007, at 3:03 PM, Kevin Sutter wrote: Derby provides a nice out of the box experience, so I vote to keep it with our set of required runtime libraries. On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote: In general I agree with Patrick. I'm +0 regarding including Derby, it's nice for the examples, but it just doesn't seem right to include a preferred database . No logical reason, just personal preference. On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: - commons-logging-1.0.4.jar (used only in CommonsLogFactory when logging is configured to use commons) I think that we should leave this out altogether. Anyone who wants to use commons logging will presumably have commons logging. - commons-pool-1.3.jar (used only in TCPRemoteCommitProvider for distributed data caching) We should keep this, since it is required for one of our built-in options, although it's unfortunate to have the extra dependency for just one bit of code. - geronimo-jms_1.1_spec-1.0.1.jar (used only in JMSRemoteCommitProvider for distributed data caching) We should leave this out, since anyone who uses the JMS RCP will need to have a JMS server, and will therefore presumably have JMS jars. - derby-10.2.2.0.jar (provided only as a convenience for getting started with the examples quickly) I think that we should keep this. My question: should we differentiate between the required libraries and the optional ones (perhaps by putting them in an /optional/ directory or something)? Does anyone have experience with how this is done with other Apache projects? I think that we should make the changes I outlined above, and we should not create an /optional/ for other things. -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: Wednesday, April 18, 2007 11:31 AM To: open-jpa-dev@incubator.apache.org Subject: [DISCUSS] required vs. optional dependencies Currently with OpenJPA, we ship with the following jars in the lib/ directory: * commons-lang-2.1.jar * commons-collections-3.2.jar * geronimo-jta_1.0.1B_spec-1.0.1.jar * geronimo-jpa_3.0_spec-1.0.jar * geronimo-j2ee-connector_1.5_spec-1.0.1.jar * serp-1.11.0.jar - commons-logging-1.0.4.jar (used only in CommonsLogFactory when logging is configured to use commons) - commons-pool-1.3.jar (used only in TCPRemoteCommitProvider for distributed data caching) - geronimo-jms_1.1_spec-1.0.1.jar (used only in JMSRemoteCommitProvider for distributed data caching) - derby-10.2.2.0.jar (provided only as a convenience for getting started with the examples quickly) The jars marked with stars (*) are the only ones that are actually required for OpenJPA to function in the common cases (the examples included in the distribution all run if you have just the starred libraries + derby). My question: should we differentiate between the required libraries and the optional ones (perhaps by putting them in an /optional/ directory or something)? Does anyone have experience with how this is done with other Apache projects? 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. -- -Michael Dick 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: [DISCUSS] OpenJPA Graduation
On Apr 23, 2007, at 2:58 PM, Marc Prud'hommeaux wrote: I'm personally rather neutral on whether OpenJPA should be a TLP vs. a sub-project. TLP seems like it allows us more flexibility and independence, so by default I would lean towards being a TLP. That's my main concern as well. However, I do notice that the DB TLP already holds other similar projects (Torque, OJB, and Apache JDO), so I wonder if the Apache board would ask questions about why they should be handled differently. There have been discussions in Apache about umbrella projects being undesirable, and the trend is toward breaking them up where there is no interdependence. There have been concerns expressed at the board level about DB becoming an umbrella prokect [sic], and about if Geronimo is not to become an umbrella. [1] There are benefits in having small projects being part of a bigger TLP. There is no fixed overhead for a small project to have a PMC chair to have to report status to the board, maintain committers and PMC members lists, monitor board meetings, monitor incubating projects, and monitor legal and community issues for the board. I don't think OpenJPA should try to avoid responsibility for these tasks. Craig [1] http://www.apache.org/foundation/records/minutes/2006/ board_minutes_2006_01_18.txt On Apr 23, 2007, at 2:49 PM, Craig L Russell wrote: OpenJPA has done a great job of forming a diverse community around a great code base whose IP has been reviewed and approved for release, and we're now a well-functioning, project in the incubator. So we are now at the stage when we should think about when and how to leave the incubator and graduate to the larger Apache community. The document at [1] describes readiness to graduate. There are two courses for graduating projects: to become an independent Apache TLP or to join an existing TLP as a sub- project. I believe that OpenJPA should become its own TLP for a few reasons: the community is already very diverse and has established a good working style; and there is no existing TLP upon which OpenJPA depends. There is some synergy with the DB project but no dependency relationship. As a TLP, OpenJPA would operate independent from other TLPs and be responsible to the Apache board. As a TLP, the OpenJPA community would decide on offering committerships to the project, and what and when to release, subject to the regulations of the ASF. So what does everyone think? Craig [1] http://incubator.apache.org/incubation/ Process_Description.html#Graduation 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! 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: [VOTE] [THIRD ATTEMPT] publish openjpa 0.9.7-incubating release
+1 to release First, Mike, this release vote request is a thing of beauty. I'm going to frame it for reference. I used mvn to get the maven artifacts of the build; all the dependent artifacts downloaded and everything worked fine with Mike's excellent repository. I ran rat on both binary and source distributions and found just one anomaly not reported earlier: docs/manual/manual.html doesn't have a license in it. I didn't look at the binary distribution with rat so I didn't catch this before. I assume that this file is generated but in future we should probably see if there is a way of including a license header in it. For now, we can mark it as being generated. Good job everyone. Craig On Apr 20, 2007, at 12:41 PM, Michael Dick wrote: OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I've taken another shot at making a release and start a vote on publishing a 0.9.7-incubating release of OpenJPA. The release candidate is at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.ziphttp://people.apache.org/%7Emikedd/staging- repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/ openjpa-project-0.9.7-incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.aschttp://people.apache.org/%7Emikedd/ staging-repository/org/apache/openjpa/openjpa-project/0.9.7- incubating/openjpa-project-0.9.7-incubating-binary.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.md5http://people.apache.org/%7Emikedd/ staging-repository/org/apache/openjpa/openjpa-project/0.9.7- incubating/openjpa-project-0.9.7-incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.asc http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.md5 http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.md5 A branch for this release candidate has been created at : https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.7- incubating-RC2 The release has been published to a staging repository on people.apache.org. The staging repository may be used in a maven 2 build file by adding the following information : . . . repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repositoryhttp:// people.apache.org/%7Emikedd/staging-repository /url /repository . . . /repositories . . . dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.7-incubating/version /dependency . . . /dependencies Known issues : There are a few .rsrc files included in the release which do not contain licensing information. The issue has been discussed in several threads on the open-jpa-dev mailing list (links follow). To summarize : orm-xsd.rsrc and persistence-xsd.rsrc are copies of the official JPA schemas under CDDL that are properly attributed in LICENSE.txt java-keywords.rsrc does not contain IP schemas-doctype.rsrc does contain IP however the parser for this file does not support comments. These issues will be addressed in a future release. For more information please see the discussion on the mailing list (roughly) starting here http://www.nabble.com/forum/ViewPost.jtp?post=10022158framed=y Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html This vote will remain open until 14:40 CST on Tuesday April 24th. A +1 indicates that you approve of the release, a -1 indicates a vote against making a release -- -Michael Dick Craig Russell DB PMC, OpenJPA PPMC [EMAIL
Re: [jira] Updated: (OPENJPA-61) Missing usage of TransactionSynchronizationRegistry
Hi Marc, I guess you need someone to run a test suite that is container-based. Aside from the TCK for JPA, running inside the container, are there other test suites that would demonstrate this functionality? Craig On Apr 22, 2007, at 2:25 PM, Marc Prud'hommeaux (JIRA) wrote: [ https://issues.apache.org/jira/browse/OPENJPA-61? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marc Prud'hommeaux updated OPENJPA-61: -- Attachment: OPENJPA-61.patch The attached patch might work. It contains a new RegistryManagedRuntime class that just uses a TransactionManager facade around a TransactionSynchronizationRegistry. This will allow us to use the standard TransactionSynchronizationRegistry interface without breaking the ManagedRuntime contracts. The only shortcoming is that direct control over the Transaction will fail (since TransactionSynchronizationRegistry doesn't provide direct access to the current Transaction). Note also that this patch will require us to update our JTA dependency from geronimo-jta_1.0.1B_spec to geronimo-jta_1.1_spec. I don't envision that being a problem, since it should be backwards- compatible. I will need someone who has access to a container that supports the TransactionSynchronizationRegistry interface to test this out before we can commit it. Missing usage of TransactionSynchronizationRegistry --- Key: OPENJPA-61 URL: https://issues.apache.org/jira/browse/OPENJPA-61 Project: OpenJPA Issue Type: Bug Components: jdbc Reporter: Kevin Sutter Assigned To: Kevin Sutter Fix For: 1.1.0 Attachments: OPENJPA-61.patch A discussion on the dev mailing list indicates that OpenJPA currently does not utilize the TransactionSynchronizationRegistry. Although OpenJPA does provide other means of finding and accessing the various TransactionManagers, we should update OpenJPA to use the standard interfaces. Following are the two notes on this subject... = === o David Jencks [EMAIL PROTECTED] to open-jpa-dev More options Sep 27 (19 hours ago) I'm trying to get openjpa running in geronimo and wonder how openjpa locates the TransactionSynchronizationRegistry. Grep'ing for TransactionSynchronizationRegistry I don't see it used anywhere in the code base. What am I missing? thanks david jencks = === o Marc Prud'hommeaux to open-jpa-dev More options Sep 27 (19 hours ago) David- We don't use TransactionSynchronizationRegistry (not yet, at least). Instead, we manually locate the TransactionManager via appserver- specific heuristics defined in openjpa-kernel/src/main/java/org/ apache/openjpa/ee/AutomaticManagedRuntime.java If the Geronimo TransactionManager is accessible from JNDI or some method invocation, you can just add it into AutomaticManagedRuntime as a default (you can test it out by specifying the openjpa.ManagedRuntime property to jndi (TransactionManagerName=java:/ GeronimoJNDINameForTransactionManager). We may add support for integration via TransactionSynchronizationRegistry in the future, but the fact that it doesn't provide support for accessing the current Transaction would mean that we would need to rework some OpenJPA internals. = === -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. 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
Fwd: [continuum] BUILD FAILURE: OpenJPA Distribution
Hi,
Could the vm used to build openjpa be given some more memory to allow
the build to go through more often?
Is this something the openjpa folks can do ourselves?
Thanks,
Craig
Begin forwarded message:
From: [EMAIL PROTECTED] open-jpa-
[EMAIL PROTECTED]
Date: April 21, 2007 2:08:08 PM PDT
To: [EMAIL PROTECTED]
Subject: [continuum] BUILD FAILURE: OpenJPA Distribution
Reply-To: open-jpa-dev@incubator.apache.org
Online report : http://vmbuild.apache.org/continuum/servlet/
continuum/target/ProjectBuild.vm/view/ProjectBuild/id/85/buildId/
119491
Build statistics:
State: Failed
Previous State: Failed
Started at: Sat, 21 Apr 2007 14:03:39 -0700
Finished at: Sat, 21 Apr 2007 14:08:07 -0700
Total time: 4m 28s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: vmbuild.apache.org
Operating system : Linux(unknown)
Java version : 1.5.0_06(Sun Microsystems Inc.)
Changes
mprudhom Changed link tag to xref since there is
no enclosed describing text.
/incubator/openjpa/trunk/openjpa-project/src/doc/
manual/ref_guide_optimization.xml
mprudhom Output multi-page manual as well as
single manual page.
/incubator/openjpa/trunk/openjpa-project/pom.xml
**
**
Output:
**
**
[INFO] Scanning for projects...
[INFO]
--
--
[INFO] Building OpenJPA Distribution
[INFO]task-segment: [clean, install]
[INFO]
--
--
[INFO] [clean:clean]
[INFO] Deleting directory /x1/continuum/working-directory/85/target
[INFO] Deleting directory /x1/continuum/working-directory/85/target/
classes
[INFO] Deleting directory /x1/continuum/working-directory/85/target/
test-classes
[INFO] [site:attach-descriptor]
[WARNING]
Artifact ant:ant:jar:1.6.5:runtime retains local scope 'runtime'
overriding broader scope 'compile'
given by a dependency. If this is not intended, modify or remove
the local scope.
Downloading: http://www.ibiblio.org/maven2/docbook/docbook-xsl/
1.67.2/docbook-xsl-1.67.2.pom
[WARNING] Unable to get resource 'docbook:docbook-xsl:pom:1.67.2'
from repository central (http://www.ibiblio.org/maven2)
[WARNING] DEPRECATED [descriptor]: Please use descriptors instead
[INFO] [assembly:attached {execution: bin}]
[INFO] Building zip: /x1/continuum/working-directory/85/target/
assembly/openjpa-project-0.9.8-incubating-SNAPSHOT-binary.zip
[WARNING] DEPRECATED [descriptor]: Please use descriptors instead
[INFO] [assembly:attached {execution: sources}]
[INFO]
--
--
[ERROR] FATAL ERROR
[INFO]
--
--
[INFO] Java heap space
[INFO]
--
--
[INFO] Trace
java.lang.OutOfMemoryError: Java heap space
[INFO]
--
--
[INFO] Total time: 4 minutes 26 seconds
[INFO] Finished at: Sat Apr 21 14:08:07 PDT 2007
[INFO] Final Memory: 11M/63M
[INFO]
--
--
**
**
Craig Russell
DB PMC
[EMAIL PROTECTED] http://db.apache.org/jdo
smime.p7s
Description: S/MIME cryptographic signature
Re: [VOTE] publish openjpa 0.9.7-incubating release
Hi Kevin, I agree that the problem with sub-selects on DB2 seems significant enough to stop the release. Craig On Apr 19, 2007, at 7:52 AM, Kevin Sutter wrote: Another alternative is to back out the changes for OPENJPA-182 until we get the complete solution.. But, looking at the changes for OPENJPA-182, that looks to be quite the job and I'm not sure how many of these parts have been touched since that commit... I would rather wait until OPENJPA-222 tests clean and then go forward with another vote... But, I am open to other suggestions. Kevin On 4/19/07, Kevin Sutter [EMAIL PROTECTED] wrote: Craig and others, Here's the scoop with OPENJPA-222... A couple of weeks ago, DaveW committed some changes to OPENJPA-182. Patrick reviewed the changes and through discussions on the dev mailing list and the Issue itself, re-worked and re-committed the changes. We dropped the ball and didn't sufficiently test these new changes against DB2 until recently. We are finding that basically any sub-selects will not work with DB2 with the changes for OPENJPA-182. The changes for OPENJPA-222 will resolve these issues. This problem (no sub-selects with DB2) seems severe enough to warrant a re-spin of the release. I know this pushes us out another couple of days, but I think from a customer perspective, it's worth the effort. As far as this 0.9.7 being bundled with some significant release... We (IBM) were planning to use the 0.9.7 release with a refresh of the EJB3 Feature Pack. Our plans have since changed, so the urgency is no longer present. I just want any OpenJPA release to be usable and not regress expected function. Thanks, Kevin On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote: This isn't the last release of openjpa. What is the urgency for fixing this before our major event (the last release before exiting the incubator)? Is this release planned to be bundled with some other significant release? Craig On Apr 18, 2007, at 4:40 PM, Michael Dick wrote: I probably should have worded that differently since I haven't run the tests against DB2. I believe Dave's team has. Dave, can you comment on how big the impact of OpenJPA-222 is? On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. I'm a little nervous about scope creep. Is there some good reason why OPENJPA-222 needs to be resolved now vs. later? -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: Michael Dick [mailto:[EMAIL PROTECTED] ] Sent: Wednesday, April 18, 2007 2:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. Personally, I think it is sufficiently ugly to release with the docbook jar to justify starting another release. However, if others disagree, I'll happily accede to the majority. For now, my vote changes to +0. I agree but like you I can be talked out of it. I'll take another look over everything and start another release tonight / tomorrow. I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. -- -Michael Dick 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. -- -Michael Dick Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/ products/jdo 408 276-5638 mailto
Integration testing
Hi Kevin, We should try to do a better job of getting test cases checked in for significant patches. Can the tests that you're using to validate the 222 changes be made available to the rest of the community? Perhaps we should expand on the integration test concept used now for examples and tck integration testing. As we develop more and more integration tests, it will become a real drag to incorporate these tests into a successful mvn build. So some strategy will be needed to be able to build quickly but run the integration tests when desired. Craig On Apr 19, 2007, at 7:52 AM, Kevin Sutter wrote: Another alternative is to back out the changes for OPENJPA-182 until we get the complete solution.. But, looking at the changes for OPENJPA-182, that looks to be quite the job and I'm not sure how many of these parts have been touched since that commit... I would rather wait until OPENJPA-222 tests clean and then go forward with another vote... But, I am open to other suggestions. Kevin On 4/19/07, Kevin Sutter [EMAIL PROTECTED] wrote: Craig and others, Here's the scoop with OPENJPA-222... A couple of weeks ago, DaveW committed some changes to OPENJPA-182. Patrick reviewed the changes and through discussions on the dev mailing list and the Issue itself, re-worked and re-committed the changes. We dropped the ball and didn't sufficiently test these new changes against DB2 until recently. We are finding that basically any sub-selects will not work with DB2 with the changes for OPENJPA-182. The changes for OPENJPA-222 will resolve these issues. This problem (no sub-selects with DB2) seems severe enough to warrant a re-spin of the release. I know this pushes us out another couple of days, but I think from a customer perspective, it's worth the effort. As far as this 0.9.7 being bundled with some significant release... We (IBM) were planning to use the 0.9.7 release with a refresh of the EJB3 Feature Pack. Our plans have since changed, so the urgency is no longer present. I just want any OpenJPA release to be usable and not regress expected function. Thanks, Kevin On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote: This isn't the last release of openjpa. What is the urgency for fixing this before our major event (the last release before exiting the incubator)? Is this release planned to be bundled with some other significant release? Craig On Apr 18, 2007, at 4:40 PM, Michael Dick wrote: I probably should have worded that differently since I haven't run the tests against DB2. I believe Dave's team has. Dave, can you comment on how big the impact of OpenJPA-222 is? On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. I'm a little nervous about scope creep. Is there some good reason why OPENJPA-222 needs to be resolved now vs. later? -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: Michael Dick [mailto:[EMAIL PROTECTED] ] Sent: Wednesday, April 18, 2007 2:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. Personally, I think it is sufficiently ugly to release with the docbook jar to justify starting another release. However, if others disagree, I'll happily accede to the majority. For now, my vote changes to +0. I agree but like you I can be talked out of it. I'll take another look over everything and start another release tonight / tomorrow. I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. -- -Michael Dick Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may
Post processing in JPA
Hi Jacek, On Apr 19, 2007, at 7:56 AM, Jacek Laskowski wrote: I thought I needed to add the class names to persistence.xml to have them post-processed. What do you mean by post-processed. There's no notion of post-processing in JPA. Post processing is a common term used to describe anything done to a .class file after being generated by the compiler. And there certainly is the notion of post processing class files in JPA. In a container, the JPA provider is given the chance to post process entities by an explicit callback. See section 7.1. Outside the container, JPA providers typically use the java agent technology to perform post processing on the classes. Some JPA providers have a static post processor that allows you to deploy applications without using agents or transformers at runtime. OpenJPA's processor is the PCEnhancer. Craig 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: [VOTE] publish openjpa 0.9.7-incubating release
Hi Eddie, On Apr 18, 2007, at 8:46 AM, Eddie O'Neil wrote: The release is looking good with two items that should be addressed and some nits. :) Major issues: - Mike's GPG key is present in site/docs/KEYS but this file needs to be copied to http://incubator.apache.org/openjpa/KEYS as well. This will make it easier to verify releases and matches the instructions on the download page. I agree. This doesn't hold up the release since it's a parallel activity. ... Minor issues: - The Maven2 repo contains two directories that probably shouldn't be part of the release -- examples/ and tck/ If you're using maven, it's unlikely that these will be of interest, but I don't have any problem with including these in the maven repo, regardless of how useful (or not) they might be there. - The .rsrc files don't have licenses -- we've discussed this before (even in this thread!). This isn't a big deal, just expect the iPMC to bring it up again. It might be well to post the results of our discussion with the VOTE for IPMC to approve release, just so people are aware that we know about it and have discussed it and our mentors agree that it's going to be fixed but not today. - The JPA XSDs are CDDL licensed and are included in the distribution. IMHO, these should be cleanroom'ed so that the question just goes away. Like the .rsrc files, this has come up before and not been an issue. I don't believe that it's possible to clean room these files. They have a perfectly compatible license. These are specified reference files, not an implementation that can have independent IP. So I don't think it's worthwhile to try to clean room them. ... Comments welcome, but let's work on addressing the first two. Eddie On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote: +1 for the 0.9.7 release. On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc don't know: This is a dtd describing document type schemas. It doesn't appear to be generated and certainly has some IP in it. I think that our parser doesn't deal with comments for this type. openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/ derby.log ok: This should be cleaned up for future releases but has no IP We should just move this to the target directory. I'm anxiously awaiting the day that Apache decides that it really is sufficient to describe licensing terms at the packaging unit level, rather than the individual file level. -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: Monday, April 16, 2007 11:40 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release +1 for release I ran Robert's Donkin's RAT program on the release, and it reported a few anomalies: No license: openjpa-project-0.9.7-incubating-source/CHANGES.txt ok: No IP here openjpa-project-0.9.7-incubating-source/RELEASE-NOTES.html don't know: I'd approve it but others in the Incubator PMC might feel otherwise. openjpa-project-0.9.7-incubating-source/openjpa-integration/tck/ windows-replacefilter.properties ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/meta/java-keywords.rsrc ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc don't know: This is a dtd describing document type schemas. It doesn't appear to be generated and certainly has some IP in it. openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/sql/sql-keywords.rsrc ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-persistence/ src/main/ resources/META-INF/services/ javax.persistence.spi.PersistenceProvider ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-persistence/ src/main/ resources/org/apache/openjpa/persistence/orm-xsd.rsrc ok: This is a copy of the official JPA schema under CDDL that is properly attributed in LICENSE.txt openjpa-project-0.9.7-incubating-source/openjpa-persistence/ src/main/
Re: [VOTE] publish openjpa 0.9.7-incubating release
On Apr 18, 2007, at 10:19 AM, Patrick Linskey wrote: [eko] Yeah -- I noticed. Just didn't know how paranoid folks tend to be about this sort of stuff since TCK details seem to be kept under wraps. None of this IP comes from the TCK itself. I don't think that the TCK license bans people from putting IP that they create while running the TCK into the open source. Right. The only thing that we need to worry about is leaking TCK IP. Which this project does not. Craig -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: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 10:17 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release The TCK dir only contains the bootstrap / glue to invoke the TCK from within our build system, and not the TCK itself. [eko] Yeah -- I noticed. Just didn't know how paranoid folks tend to be about this sort of stuff since TCK details seem to be kept under wraps. - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip That dependency is unnecessary -- it's needed to build the docs, but not by the runtime. [eko] Cool, maybe it's easier to delete than to figure out how it's licensed. ;) On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip That dependency is unnecessary -- it's needed to build the docs, but not by the runtime. -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: Eddie O'Neil [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 8:46 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release The release is looking good with two items that should be addressed and some nits. :) Major issues: - Mike's GPG key is present in site/docs/KEYS but this file needs to be copied to http://incubator.apache.org/openjpa/KEYS as well. This will make it easier to verify releases and matches the instructions on the download page. - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip Minor issues: - The Maven2 repo contains two directories that probably shouldn't be part of the release -- examples/ and tck/ - The .rsrc files don't have licenses -- we've discussed this before (even in this thread!). This isn't a big deal, just expect the iPMC to bring it up again. - The JPA XSDs are CDDL licensed and are included in the distribution. IMHO, these should be cleanroom'ed so that the question just goes away. Like the .rsrc files, this has come up before and not been an issue. - The .zip distribution contains .asc files for the .md5 and .sha1 files, which are unnecessary. - The source distribution contains a derby.log file at: source-dist/openjpa-persistence-jdbc/derby.log Comments welcome, but let's work on addressing the first two. Eddie On 4/17/07, Kevin Sutter [EMAIL PROTECTED] wrote: +1 for the 0.9.7 release. On 4/16/07, Patrick Linskey [EMAIL PROTECTED] wrote: openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc don't know: This is a dtd describing document type schemas. It doesn't appear to be generated and certainly has some IP in it. I think that our parser doesn't deal with comments for this type. openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/ derby.log ok: This should be cleaned up for future releases but has no IP We should just move this to the target directory. I'm anxiously awaiting the day that Apache decides that it really is sufficient to describe licensing terms at the
Re: [VOTE] publish openjpa 0.9.7-incubating release
For the record, I'm still +1 for release. But if you want to cut another to fix the minor items that have been surfaced, it's ok with me. Craig On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote: Mike-- RE the KEYS file, you can just ssh to people.apache.org and check the KEYS file out directly into /www/incubator.apache.org/openjpa/ directory. No uploading necessary! :) To be sure -- the rest of the items are just nits which could mostly be cleaned up just by deleting the directories / files after they're uploaded. I don't have strong feelings about them, so just do whatever the community feels is best. Certainly, it's fine to ship them for 0.9.7. Cheers, Eddie On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote: Thanks Marc, How do I upload my key to http://incubator.apache.org/openjpa/ KEYS ? The only documentation I've found indicates that I need to upload it, but not where the key needs to go. Before I create another release candidate (to remove the docbook jar), should we try to address the other minor issues? Craig and Patrick have responded to most of them, but there are a few others. Minor issues: - The .zip distribution contains .asc files for the .md5 and .sha1 files, which are unnecessary. They're unnecessary, but I've been ignoring them since they aren't hurting anything. It isn't too hard to get rid of them though. I think the gpg plugin for maven signs the .md5 and sha1 files too (I'd have to check though). - The source distribution contains a derby.log file at: source-dist/openjpa-persistence-jdbc/derby.log This is pretty easy to clean up, and I'll do that before I create another release candidate. The other issues Craig and Patrick have responded to. If any of them can be fixed quickly then we can include them in the new release candidate. On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Good idea ... I've gone ahead and done that. It should make things a little easier to manage. On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote: This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. Is it possible to invert that, so that we only include certain 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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, April 18, 2007 10:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote: - The binary distribution contains a new JAR file whose license is unclear; this is: binary-dist/lib/docbook-xsl-1.67.2.zip That dependency is unnecessary -- it's needed to build the docs, but not by the runtime. This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. I've gone ahead and fixed this in the trunk by adding it to the exclude list (revision 530094). 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. -- -Michael Dick 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: [VOTE] publish openjpa 0.9.7-incubating release
On Apr 18, 2007, at 12:53 PM, Patrick Linskey wrote: ... but we can run the incubator and the openjpa votes in parallel, right? If we're pretty sure that with the removal of that jar, we'll be happy, then we could rebuild and start off those two votes at the same time. Yes, this is true. Craig -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, April 18, 2007 12:30 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release Hi Mike, On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. If I go back and remove the jar, republish etc. I'm assuming we'll have to restart the clock on the vote, correct me if I'm wrong in this regard. Yes, changing the bits restarts the clock. Craig On 4/18/07, Craig L Russell [EMAIL PROTECTED] wrote: For the record, I'm still +1 for release. But if you want to cut another to fix the minor items that have been surfaced, it's ok with me. Craig On Apr 18, 2007, at 11:42 AM, Eddie O'Neil wrote: Mike-- RE the KEYS file, you can just ssh to people.apache.org and check the KEYS file out directly into /www/incubator.apache.org/openjpa/ directory. No uploading necessary! :) To be sure -- the rest of the items are just nits which could mostly be cleaned up just by deleting the directories / files after they're uploaded. I don't have strong feelings about them, so just do whatever the community feels is best. Certainly, it's fine to ship them for 0.9.7. Cheers, Eddie On 4/18/07, Michael Dick [EMAIL PROTECTED] wrote: Thanks Marc, How do I upload my key to http://incubator.apache.org/openjpa/ KEYS ? The only documentation I've found indicates that I need to upload it, but not where the key needs to go. Before I create another release candidate (to remove the docbook jar), should we try to address the other minor issues? Craig and Patrick have responded to most of them, but there are a few others. Minor issues: - The .zip distribution contains .asc files for the .md5 and .sha1 files, which are unnecessary. They're unnecessary, but I've been ignoring them since they aren't hurting anything. It isn't too hard to get rid of them though. I think the gpg plugin for maven signs the .md5 and sha1 files too (I'd have to check though). - The source distribution contains a derby.log file at: source-dist/openjpa-persistence-jdbc/derby.log This is pretty easy to clean up, and I'll do that before I create another release candidate. The other issues Craig and Patrick have responded to. If any of them can be fixed quickly then we can include them in the new release candidate. On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Good idea ... I've gone ahead and done that. It should make things a little easier to manage. On Apr 18, 2007, at 10:45 AM, Patrick Linskey wrote: This is there because we draw in all the dependencies that we don't explicitly exclude in the openjpa-project/assembly.xml, and at some point, someone (probably me) added docbook-xsl as a dependency so as to ensure that the docbook processing phase had access to the stylesheets. Is it possible to invert that, so that we only include certain 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: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf Of Marc Prud'hommeaux Sent: Wednesday, April 18, 2007 10:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On Apr 18, 2007, at 10:11 AM, Patrick Linskey wrote: - The binary distribution contains a new
Re: [VOTE] publish openjpa 0.9.7-incubating release
This isn't the last release of openjpa. What is the urgency for fixing this before our major event (the last release before exiting the incubator)? Is this release planned to be bundled with some other significant release? Craig On Apr 18, 2007, at 4:40 PM, Michael Dick wrote: I probably should have worded that differently since I haven't run the tests against DB2. I believe Dave's team has. Dave, can you comment on how big the impact of OpenJPA-222 is? On 4/18/07, Patrick Linskey [EMAIL PROTECTED] wrote: I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. I'm a little nervous about scope creep. Is there some good reason why OPENJPA-222 needs to be resolved now vs. later? -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: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 18, 2007 2:24 PM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] publish openjpa 0.9.7-incubating release On 4/18/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Michael- On Apr 18, 2007, at 12:27 PM, Michael Dick wrote: I'd rather not cut another release, but I think we do need to resolve the issue with the docbook jar. If we can live with the extra jar then the vote can proceed. Personally, I think it is sufficiently ugly to release with the docbook jar to justify starting another release. However, if others disagree, I'll happily accede to the majority. For now, my vote changes to +0. I agree but like you I can be talked out of it. I'll take another look over everything and start another release tonight / tomorrow. I'm a little nervous about OpenJPA-222. From talking with Dave it sounds like it has a large effect on DB2. I'd like to get that issue resolved if possible. -- -Michael Dick 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. -- -Michael Dick 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: [VOTE] publish openjpa 0.9.7-incubating release
+1 for release I ran Robert's Donkin's RAT program on the release, and it reported a few anomalies: No license: openjpa-project-0.9.7-incubating-source/CHANGES.txt ok: No IP here openjpa-project-0.9.7-incubating-source/RELEASE-NOTES.html don't know: I'd approve it but others in the Incubator PMC might feel otherwise. openjpa-project-0.9.7-incubating-source/openjpa-integration/tck/ windows-replacefilter.properties ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/meta/java-keywords.rsrc ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/schema/schemas-doctype.rsrc don't know: This is a dtd describing document type schemas. It doesn't appear to be generated and certainly has some IP in it. openjpa-project-0.9.7-incubating-source/openjpa-jdbc/src/main/ resources/org/apache/openjpa/jdbc/sql/sql-keywords.rsrc ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-persistence/src/main/ resources/META-INF/services/javax.persistence.spi.PersistenceProvider ok: No IP here openjpa-project-0.9.7-incubating-source/openjpa-persistence/src/main/ resources/org/apache/openjpa/persistence/orm-xsd.rsrc ok: This is a copy of the official JPA schema under CDDL that is properly attributed in LICENSE.txt openjpa-project-0.9.7-incubating-source/openjpa-persistence/src/main/ resources/org/apache/openjpa/persistence/persistence-xsd.rsrc ok: This is a copy of the official JPA schema under CDDL that is properly attributed in LICENSE.txt openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/ derby.log ok: This should be cleaned up for future releases but has no IP openjpa-project-0.9.7-incubating-source/openjpa-persistence-jdbc/src/ test/resources/org/apache/openjpa/persistence/xml/orm.xml ok: This is a test case orm.xml file that probably should have license notice in it for next time. But I won't vote to hold up the release for it. Craig On Apr 16, 2007, at 9:10 AM, Michael Dick wrote: OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/Incubation_Policy.html#Releases , I've taken another shot at making a release and start a vote on publishing a 0.9.7-incubating release of OpenJPA. The release candidate is at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.ziphttp://people.apache.org/%7Emikedd/staging- repository/org/apache/openjpa/openjpa-project/0.9.7-incubating/ openjpa-project-0.9.7-incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.aschttp://people.apache.org/%7Emikedd/ staging-repository/org/apache/openjpa/openjpa-project/0.9.7- incubating/openjpa-project-0.9.7-incubating-binary.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.md5http://people.apache.org/%7Emikedd/ staging-repository/org/apache/openjpa/openjpa-project/0.9.7- incubating/openjpa-project-0.9.7-incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.asc http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.md5 http://people.apache.org/%7Emikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.md5 A branch for this release candidate has been created at : https://svn.apache.org/repos/asf/incubator/openjpa/branches/0.9.7- incubating-RC2 https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.7- incubating/ The release has been published to a staging repository on people.apache.org. The staging repository may be used in a maven 2 build file by adding the following information : . . . repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repository /url
Re: Source license headers in OpenJPA
Good exercise anyway. I notice you found some files with no license headers at all. Good job. Craig On Apr 14, 2007, at 2:57 PM, Marc Prud'hommeaux wrote: And that's why vi is the best editor in the world :) On Apr 14, 2007, at 2:53 PM, Eddie O'Neil wrote: Nice work -- 26 minutes by my count. :) Eddie On 4/14/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: I just went ahead and manually updated the license headers, just to get this taken care of quickly. On Apr 14, 2007, at 2:30 PM, Craig L Russell wrote: Hi Eddie, Removing Cliff from this discussion; sorry for the spam, Cliff, but I recall you asking for it... ;-) On Apr 14, 2007, at 2:21 PM, Eddie O'Neil wrote: Craig-- You're quite right; my apologies for not having caught this before now. Given that this policy went into effect in November 2006, IMHO the 0.9.7 release that we're currently reviewing and voting on needs to be updated to include the appropriate headers. Thoughts? The Release Manager needs to rescind the vote for 0.9.7 and read the document below in detail. It contains references to scripts that will update the license headers easier than manually editing all the files. Craig Eddie On 4/14/07, Craig L Russell [EMAIL PROTECTED] wrote: The license headers we are using are in conflict with current practice, as documented here: http://www.apache.org/legal/src-headers.html There was a big discussion about this topic, but the above is normative as of today. See the discussion in this message: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ 200612.mbox/% [EMAIL PROTECTED] Bottom line, there should not be a copyright notice in the source headers, only a license notice. 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! 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! 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: Source license headers in OpenJPA
Hi Marc, Thanks for the heads-up. I'll follow up with the responsible team and see if it can be improved. Craig On Apr 15, 2007, at 12:48 PM, Marc Prud'hommeaux wrote: I notice you found some files with no license headers at all. I had actually known those files existed, but I didn't know if the format supported comments. They were services files, and I investigated and found that our services parser actually does support comments. However, the parser in javax.persistence.Persistence (that parses the META-INF/ javax.persistence.spi.PersistenceProvider file) surprisingly doesn't support comments, so I had to leave the license out of that file. On Apr 14, 2007, at 11:21 PM, Craig L Russell wrote: Good exercise anyway. I notice you found some files with no license headers at all. Good job. Craig On Apr 14, 2007, at 2:57 PM, Marc Prud'hommeaux wrote: And that's why vi is the best editor in the world :) On Apr 14, 2007, at 2:53 PM, Eddie O'Neil wrote: Nice work -- 26 minutes by my count. :) Eddie On 4/14/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: I just went ahead and manually updated the license headers, just to get this taken care of quickly. On Apr 14, 2007, at 2:30 PM, Craig L Russell wrote: Hi Eddie, Removing Cliff from this discussion; sorry for the spam, Cliff, but I recall you asking for it... ;-) On Apr 14, 2007, at 2:21 PM, Eddie O'Neil wrote: Craig-- You're quite right; my apologies for not having caught this before now. Given that this policy went into effect in November 2006, IMHO the 0.9.7 release that we're currently reviewing and voting on needs to be updated to include the appropriate headers. Thoughts? The Release Manager needs to rescind the vote for 0.9.7 and read the document below in detail. It contains references to scripts that will update the license headers easier than manually editing all the files. Craig Eddie On 4/14/07, Craig L Russell [EMAIL PROTECTED] wrote: The license headers we are using are in conflict with current practice, as documented here: http://www.apache.org/legal/src-headers.html There was a big discussion about this topic, but the above is normative as of today. See the discussion in this message: http://mail-archives.apache.org/mod_mbox/www-legal-discuss/ 200612.mbox/% [EMAIL PROTECTED] Bottom line, there should not be a copyright notice in the source headers, only a license notice. 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! 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! 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! 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: [VOTE] publish openjpa 0.9.7-incubating release
Hi Marc, Artifacts need to be approved (voted on by the PMC) before they are put into repositories. The 0.9.6 release was put into the incubating repository only after it was approved by the IPMC. I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa-all.0.9.7- incubating.jar should be part of the vote and available in the staging repository. Craig On Apr 13, 2007, at 12:09 PM, Marc Prud'hommeaux wrote: Craig- I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would enable folks using maven to simply put the five lines of code naming the dependency into their pom and put the incubating repository into their maven repositories list and they would be done. Note that they can do that already with the existing artifacts, since Maven downloads transitive dependencies. For example, this pom.xml works fine for me in that it downloads and uses all of the OpenJPA libraries and dependencies: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdsome-project/groupId artifactIdsome-artifact/artifactId packagingjar/packaging nameMy Project/name version1.0.0/version repositories repository idapache-snapshots/id urlhttp://people.apache.org/repo/m2-incubating- repository/url /repository /repositories dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.6-incubating/version /dependency /dependencies /project There might be some other good reasons to make a separate distribution that bundles all of the jars into a single uber-jar, but, as I mentioned before, I personally don't think it is worth the effort, especially for a project that is so component-oriented. On Apr 13, 2007, at 11:55 AM, Craig L Russell wrote: Hi Michael, Thanks for all the work. I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would enable folks using maven to simply put the five lines of code naming the dependency into their pom and put the incubating repository into their maven repositories list and they would be done. Was I just dreaming this up? Thanks, Craig On Apr 12, 2007, at 3:20 PM, Michael Dick wrote: OpenJPA People- In accordance with the Incubating Releases guidelines at http://incubator.apache.org/incubation/ Incubation_Policy.html#Releases , I've taken a shot at making a release and start a vote on publishing a 0.9.7-incubating release of OpenJPA. The release candidate is at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip The GPG signature and MD5 checksums are at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-binary.zip.md5 The sources, sources GPG signature and sources MD5 checksum are available at: http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.asc http://people.apache.org/~mikedd/staging-repository/org/apache/ openjpa/openjpa-project/0.9.7-incubating/openjpa-project-0.9.7- incubating-source.zip.md5 I have tagged the sources at: https://svn.apache.org/repos/asf/incubator/openjpa/tags/0.9.7- incubating/ Please vote to publish this incubating release on the project Web page: http://cwiki.apache.org/openjpa/downloads.html This vote will remain open until 5:20 CST on Tuesday April 17th (three business days). A +1 indicates that you approve of the release, a -1 indicates a vote against making a release -- -Michael Dick 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! 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: [VOTE] publish openjpa 0.9.7-incubating release
Hi Mike, I now understand that your message only mentioned a subset of the artifacts that we're planning on publishing for the release of 0.9.7. On Apr 13, 2007, at 1:54 PM, Michael Dick wrote: Marc beat me to it, but in case this helps here's the xml that can be used to access the staging repository : repositories repository idstaging-repository/id namemikedd's staging repository/name url http://people.apache.org/~mikedd/staging-repositoryhttp:// people.apache.org/%7Emikedd/staging-repository /url /repository . . . /repositories All the OpenJPA artifacts can be accessed this way (at least I was able to download them). If there are other artifacts that we need to publish then I'll go ahead and put them on people.apache.org/~mikedd too. Maybe we just need to include these instructions in the email that we send out for the vote? Yes, I think this would make it clear that we're not releasing just the binary and source zip files but the binary maven jar and pom artifacts as well. It was the message not the staging of the artifacts that threw me off. Thanks! Craig Thanks, On 4/13/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Craig- I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. I'm not sure I completely understand your issue, but I am guessing you are either asking whether other maven-friendly jar artifacts were created for the release, or else whether those jar artifacts need to be listed and voted on. In the previous release, we just voted on the final binary (http:// people.apache.org/~mikedd/staging-repository/org/apache/openjpa/ openjpa-project/0.9.7-incubating/openjpa-project-0.9.7-incubating- binary.zip). The deploy process does also deploy the other module jars (e.g., see http://people.apache.org/~mikedd/staging-repository/ org/apache/openjpa/openjpa-all/0.9.7-incubating/), so you should be able access them in a pom.xml just like any repository. AFAIK, this is how all the other projects that use Maven have done it (e.g., ActiveMQ). Since the other deployed artifacts are either identical to, or derivative from, the binary assembly, it seems to me that listing every uploaded artifact might be needlessly cumbersome. Please let me know if I have mis-understood your issue. On Apr 13, 2007, at 12:40 PM, Craig L Russell wrote: Hi Marc, Artifacts need to be approved (voted on by the PMC) before they are put into repositories. The 0.9.6 release was put into the incubating repository only after it was approved by the IPMC. I'm really asking that the 0.9.7 release that we plan to put into the incubating repository needs to be put to a vote at the same time as we release the other artifacts. The pom.xml and the openjpa- all.0.9.7-incubating.jar should be part of the vote and available in the staging repository. Craig On Apr 13, 2007, at 12:09 PM, Marc Prud'hommeaux wrote: Craig- I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would enable folks using maven to simply put the five lines of code naming the dependency into their pom and put the incubating repository into their maven repositories list and they would be done. Note that they can do that already with the existing artifacts, since Maven downloads transitive dependencies. For example, this pom.xml works fine for me in that it downloads and uses all of the OpenJPA libraries and dependencies: ?xml version=1.0 encoding=UTF-8? project modelVersion4.0.0/modelVersion groupIdsome-project/groupId artifactIdsome-artifact/artifactId packagingjar/packaging nameMy Project/name version1.0.0/version repositories repository idapache-snapshots/id urlhttp://people.apache.org/repo/m2-incubating- repository/url /repository /repositories dependencies dependency groupIdorg.apache.openjpa/groupId artifactIdopenjpa-all/artifactId version0.9.6-incubating/version /dependency /dependencies /project There might be some other good reasons to make a separate distribution that bundles all of the jars into a single uber-jar, but, as I mentioned before, I personally don't think it is worth the effort, especially for a project that is so component- oriented. On Apr 13, 2007, at 11:55 AM, Craig L Russell wrote: Hi Michael, Thanks for all the work. I thought we were going to also release a maven download for the jar file containing all the openjpa stuff and a pom that contains the dependencies. This would
Re: state-of-the art attribute initialization in persistent pojos?
Hi Hans,
On Apr 12, 2007, at 8:43 AM, Hans J. Prueller wrote:
hi,
as you know I am switching from EJB2.1 CMP to JPA (OpenJPA). I'd
like to know the preferred way to perform attribute initialisation
of newly created entity instances, e.g. we initialized our EJB2.1
CMP entity beans with
ejbCreate(String cid, Integer someOtherValue)
{
setabc();
setdef();
}
//and ejbPostCreate optionally
as far as I know, the JPA spec requires a no-arg constructor - so
when providing a constructor with the same args that we have used
in ejbCreate before, we cannot ensure that some developer calls the
no-arg constructor by default.
The no-arg constructor can be private. The reason it's required is so
the implementation doesn't have to guess what the right values are
for final variables. But there's no requirement to make this
constructor available to your applications.
is there any other-more elegant way to force new entity instance
initialization?
There's no requirement for an ejbCreate and a separate ejbPostCreate
for relationships. So you are really free to do whatever you like for
the application contract. Have as many constructors as you like and
put whatever initialization into them.
Just don't initialize the values of generated fields...
Craig
regards,
HANS
===
virtually hanzz...
http://hanzz.zapto.org http://hanzz.zapto.org (personal)
http://www.cse.dmu.ac.uk/~hansp http://www.cse.dmu.ac.uk/~hansp
(research)
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: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Michael, On Apr 10, 2007, at 3:40 PM, Michael Dick wrote: Hi Craig, Well I didn't intentionally remove them :-). It looks like they were removed by the maven plugin and this is one of the automated commits that it does. Looks like another gotcha with the tool. The maven developers are Apache folk so it must be that the tool isn't properly set up. They know about Apache licenses. I have found the maven doc to be a bit abstruse so it wouldn't surprise me to find a special setting deep in the pom.xml that tells maven to build an Apache release... Maybe we have to have a LICENSE.xml available somewhere for maven to stuff into the artifacts? I'm going to rollback the changes again and see if I can fix the endline and the copyright problems. For the time being I'll leave the artifacts on people.apache.org/~mikedd. There should be another set of commits coming through later tonight tonight. Thanks for noticing the copyright problem. Many eyes make light reading? ;-) Good job so far, by the way. I expected it would take several tries to get the process working smoothly. For me, the more important result of this exercise is the process; the release is secondary. Craig On 4/10/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320 = = --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml Tue Apr 10 14:59:02 2007 @@ -1,22 +1,4 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Copyright 2006 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -project xmlns=http://maven.apache.org/POM/4.0.0; - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.apache.openjpa/groupId artifactIdopenjpa-examples/artifactId @@ -27,7 +9,7 @@ parent groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId -version0.9.7-incubating-SNAPSHOT/version +version0.9.7-incubating/version 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! -- -Michael Dick 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: OPENJPA-134 and the 0.9.7 release
Generally in favor of including this performance patch with the release. Just a few questions: 1. How good is the patch? Has it been put through whatever extensive Unit Tests tests anyone has? 2. How easy is it to respin the release? I'd hope that this is a matter of a few hours but I'm not the one doing the work ;-) Procedurally there is no issue since Mike hasn't yet called for a vote. I'd be happy if the patch were included in the release candidate because it's the release candidate that the community should be testing. And if this patch has any issues, we'll hear about it. Craig On Apr 11, 2007, at 2:09 PM, Kevin Sutter wrote: Question... Now that Abe has graciously resolved OpenJPA-134 ( https://issues.apache.org/jira/browse/OPENJPA-134), I would really like to see this get included into the 0.9.7 release. This fix looks to resolve the redundant sql joins that were dogging the performance of certain benchmarks. By including this fix in the 0.9.7 release, I think our OpenJPA story would be all that much better. Since we haven't started a vote yet, are there any issues with either re-cutting the 0.9.7 branch or applying Abe's fix to the 0.9.7 branch before starting a vote? I would assume that neither of these options would cause much headache for Mike (famous last words)... Kevin 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: Testing an OpenJPA module
Hi Pinaki, On Apr 10, 2007, at 6:44 PM, Pinaki Poddar wrote: provide a patch. Will such a patch be given to Glassfish project? But some kind of committer-level privilege will be required, i suppose. have added few more informative messages to distinguish between different ways persistence unit creation/ lookup can fail. please advise on how to proceed on contributing a patch. This is great. Can you please file a Glassfish/persistence issue in their issue tracker and attach your patch? If you have trouble doing this, I'll be glad to help some more... Thanks! Craig Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 10, 2007 4:14 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode- store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl 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. 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! 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. 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: Can I reuse instances?
Hi Dain, On Apr 10, 2007, at 12:58 PM, Dain Sundstrom wrote: On Apr 9, 2007, at 5:44 PM, Craig L Russell wrote: Hi Dain, On Apr 9, 2007, at 11:10 AM, Dain Sundstrom wrote: On Apr 8, 2007, at 1:56 PM, Craig L Russell wrote: Hi Dain, I haven't looked in detail at the life cycle of CMP beans in a couple of years, but in general you can't simply keep the state of the underlying Entities through the life cycle. CMP beans are pooled and reused in transaction contexts and you have to load the state at specific points in the life cycle. It depends on the commit option the container is using. In commit option A, you assume the cmp engine is the sole user of the database, so you don't need to load. Normally people use commit option B where you keep instances activated with a specific primary key and reload the data in each tx. Using the primary key stored in the CMP bean to do em.find at the appropriate time is the obvious way to take advantage of the em second level cache. To the extent that this is not efficient, we should fix it in the JPA layer not the CMP layer. I would prefer to keep as much of the CMP stuff on the CMP side as possible so the JPA implementation can focus on JPA issues. One of the assumption of JPA is that entities are light weight and cheap to create, so you take the safe route and construct a new one when every you need an instance. In CMP the assumption is that entity instances are expensive to create, so less safe route and you pool them. Reusing instances is really a CMP problem, but I don't think it can be implemented without the help of the JPA engine. I'm afraid we're getting wrapped around the axle on definitions. Here's what I'm trying to get across: CMP Entity Beans are expensive to create and there's a lot of required behavior to manage them. You pretty much have to implement the life cycle in the spec. It's your choice how to implement the state part of the beans. You can use wrappers around various kinds of state objects like ResultSet or generated classes that contain fields with the state. Your implementation uses JPA Entities to hold the state. These JPA Entities are not at all specified by CMP Entity Beans. JPA Entities as cheap to create so all you need to do is hold on to the ids and when you need state from the database, ask JPA EntityManager for the state. If the state is already in the second level cache, this is very cheap to access. In my implementation the CMP entity is the JPA entity. They are the same object. There are no state holders. Now I understand. I don't think the design works, from lots of different perspectives. We choose this design to easy the transition from CMP to JPA but has the drawback that we are completely reliant on the JPA implementation for instance management. I don't think the design can work. The CMP protocol requires separating the CMP instance from its state. You are generating the CMP concrete implementation class as part of deployment, and the concrete class needs to contain state or a reference to state. My experience is that keeping state directly in the CMP bean isn't likely to work well. Sorry for the distracting comments. I didn't imagine that you were trying to directly persist CMP beans. Craig -dain 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: Testing an OpenJPA module
FYI, Persistence is an open source project at Glassfish. Anyone, even an OpenJPA contributor, who wants to contribute to the project for example to improve the error messages, is welcome to look at the sources and provide a patch. I know people who will be happy to commit usability patches. ;-) Craig On Apr 10, 2007, at 1:54 PM, Pinaki Poddar wrote: The error message could have been more specific in the following way: a) no META-INF/persistence.xml has not been found in classpath b) META-INF/persistence.xml has been found but there is no 'ode-store' unit defined in it. c) META-INF/persistence.xml has been found but provider can not be loaded/invoked When I first encountered this error, my interpreation was (b) from the way the message was worded. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacek Laskowski Sent: Tuesday, April 10, 2007 2:52 PM To: open-jpa-dev@incubator.apache.org Subject: Re: Testing an OpenJPA module On 4/10/07, Marc Prud'hommeaux [EMAIL PROTECTED] wrote: Glad you got it fixed. It's annoying that javax.persistence.Persistence doesn't provide more of a clue as to why it failed. I wonder what else you'd like to see other than what's already printed out? It tells exactly why it's failed - No Persistence provider for EntityManager named ode-store is just a JPA version of NoClassDefFoundError in pure Java. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl 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. 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: svn commit: r527320 [1/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
Hi Mike, Did you accidentally remove the licenses from the xml files??? Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- examples/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-examples/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-examples/ pom.xml Tue Apr 10 14:59:02 2007 @@ -1,22 +1,4 @@ -?xml version=1.0 encoding=UTF-8? -!-- - Copyright 2006 The Apache Software Foundation. - - Licensed under the Apache License, Version 2.0 (the License); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an AS IS BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --- -project xmlns=http://maven.apache.org/POM/4.0.0; - xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; - xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; +project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http:// maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.apache.openjpa/groupId artifactIdopenjpa-examples/artifactId @@ -27,7 +9,7 @@ parent groupIdorg.apache.openjpa/groupId artifactIdopenjpa/artifactId -version0.9.7-incubating-SNAPSHOT/version +version0.9.7-incubating/version 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: svn commit: r527320 [2/2] - in /incubator/openjpa/branches/0.9.7-incubating: ./ openjpa-all/ openjpa-examples/ openjpa-integration/ openjpa-integration/examples/ openjpa-integration/tck/ openjpa-j
This checkin looks like a line ending mismatch. All xml files should be specified as eol-style native. Craig On Apr 10, 2007, at 2:59 PM, [EMAIL PROTECTED] wrote: Modified: incubator/openjpa/branches/0.9.7-incubating/openjpa- project/pom.xml URL: http://svn.apache.org/viewvc/incubator/openjpa/branches/0.9.7- incubating/openjpa-project/pom.xml? view=diffrev=527320r1=527319r2=527320 == --- incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ pom.xml (original) +++ incubator/openjpa/branches/0.9.7-incubating/openjpa-project/ pom.xml Tue Apr 10 14:59:02 2007 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: Can I reuse instances?
Hi Dain, On Apr 8, 2007, at 12:17 AM, Dain Sundstrom wrote: Is it possible to reuse instances from transaction to transaction? I would like to be able to create a bean in one transaction, detach it and reattach the same instance in a new transaction. My goal here is specifically to reuse instances across transactions because they have a very expensive creation cost Do you have some reason to believe this? Entities are cheap. They're not like CMP beans that are so expensive they need to be pooled. Creating Entities from their second level cached versions (em.find) should be cheaper than merging because merging requires iterating the detached Entity and populating the transaction context Entity. Getting an Entity from the second level cache is extremely efficient. , and no I can not redesign the system. Which system are you referring to? If you're using Entities as the backing persistent objects for CMP beans, there are lots of different approaches... Craig I tried a quick test case using merge, but merge returned a new instance: beginTx(); Employee dain = entityManager.find(Employee.class, dainPk); assertEquals(dain.getFirstName(), Dain); commitTx(); beginTx(); assertSame(dain, entityManager.merge(dain)); assertEquals(david.getFirstName(), Dain); commitTx(); When I try to use the refresh method, OpenJPA complains that the entity is not managed by this context. So is there anyway for me to reuse instances? -dain 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: Can I reuse instances?
Hi Dain, I haven't looked in detail at the life cycle of CMP beans in a couple of years, but in general you can't simply keep the state of the underlying Entities through the life cycle. CMP beans are pooled and reused in transaction contexts and you have to load the state at specific points in the life cycle. Using the primary key stored in the CMP bean to do em.find at the appropriate time is the obvious way to take advantage of the em second level cache. To the extent that this is not efficient, we should fix it in the JPA layer not the CMP layer. Craig On Apr 8, 2007, at 1:15 PM, Dain Sundstrom wrote: Thanks for the great info Patrick. For now, I'm going to leave my implementation the way it is, without instance reuse, and wait until someone complains loudly. BTW in CMP there are a several places in the lifecycle of entities that people like to reuse beans... 1) Beans are created and the ejb context is set into them 2) A primary key is assigned 3) Data is loaded into the bean People like to reuse instances at all three levels. The solution you suggest below addresses the first. Would it be possible to hook the cache to give the OpenJPA system an entity with data already loaded? Anyway, for not I'm just going to wait and see if anyone deeply cares about this feature. Thanks for help, -dain On Apr 8, 2007, at 8:56 AM, Patrick Linskey wrote: Hi, The easy way to do this is with extended persistence contexts. In an extended persistence context, your working set of objects lasts for the duration of the entity manager, not the transaction. In a JTA environment, the container is supposed to set things up so that EMs are transactional by default. To the best of my knowledge, between this rule and the persistence context propagation rule, this means that the container creates an EM proxy that gets injected / looked up, and that internally delegates through to the right EM internally. (I'm assuming that you're doing this for your EJB2 container work.) So, going with an extended PC is probably not sufficient for you, if you want to be spec-compliant. One thing that you could do, though, is make your EM proxy smart about holding onto a single EM for a long amount of time for use in transactions, but only use that EM during transactions. This would be closer to spec-compliant behavior, but wouldn't be 100% there. The 100% solution would be to change OpenJPA to delegate to a pluggable factory for creation of new instances. This would require creating an interface with the two pcNewInstance() signatures in PersistenceCapable, and changing the nine places in code that use that method directly to call the factory instead. Then, you could plug in whatever instance pooling logic you prefer, and you'd be in good shape. You'd need to figure out some way to know when to re-pool the instances, but in a container environment, that shouldn't be that hard. Note that you wouldn't want to use an Synchronization.afterCompletion() callback, since if it's detached, the instance might be used after completion in a rendering step or something of the sort, or it might be tucked away in session state for use later on. Of course, if you've got a pluggable instance factory, you'd have some other alternates as well, such as creating clones or something of the sort. Out of curiosity, what is slow about creating your instances? -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: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Sunday, April 08, 2007 12:18 AM To: open-jpa-dev@incubator.apache.org Subject: Can I reuse instances? Is it possible to reuse instances from transaction to transaction? I would like to be able to create a bean in one transaction, detach it and reattach the same instance in a new transaction. My goal here is specifically to reuse instances across transactions because they have a very expensive creation cost, and no I can not redesign the system. I tried a quick test case using merge, but merge returned a new instance: beginTx(); Employee dain = entityManager.find(Employee.class, dainPk); assertEquals(dain.getFirstName(), Dain); commitTx(); beginTx(); assertSame(dain, entityManager.merge(dain)); assertEquals(david.getFirstName(), Dain); commitTx(); When I try to use the
Fwd: [repo] /www/people.apache.org/repo/m2-incubating-repository/
Hi Mike, Something is wrong with the openjpa release process. Artifacts should not be uploaded to the repository until they are voted out of the project. Until they are ready, you should stage the proposed release, sign it, and after you're sure it's ready to go, call for a review on the dev list, and then call for a vote on the incubator general alias and dev list. You only need one checksum but need a gpg ascii armored signature. So you need the artifact and the artifact.asc (gpg signature) and artifact.md5 to be in the staging area. The sha1 is not needed. This should be part of the release process that's documented... Craig Begin forwarded message: From: Carlos Sanchez [EMAIL PROTECTED] Date: April 8, 2007 12:40:01 PM PDT To: [EMAIL PROTECTED] Cc: repository@apache.org Subject: Re: [repo] /www/people.apache.org/repo/m2-incubating- repository/ Reply-To: repository@apache.org please add PGP signatures, it's apache policy to sign all releases take a look at the latest maven parent pom on how to use the gpg plugin for automatic signing http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/maven- parent-5.pom On 8 Apr 2007 08:17:08 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Repository changed == Repository: /www/people.apache.org/repo/m2-incubating-repository/ Added - [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating.pom [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating-site.xml [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating-site.xml.md5 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/openjpa-0.9.7- incubating-site.xml.sha1 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/openjpa- jdbc-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-xmlstore/0.9.7-incubating/ openjpa-xmlstore-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-jdbc-5/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-jdbc-5/0.9.7-incubating/ openjpa-jdbc-5-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-jdbc-5/0.9.7-incubating/ openjpa-jdbc-5-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-jdbc-5/0.9.7-incubating/ openjpa-jdbc-5-0.9.7-incubating.jar.sha1 [mikedd]
Re: [repo] /www/people.apache.org/repo/m2-incubating-repository/
Other projects use the people.apache.org/~mikedd/xxx as the staging repository while working through the release issues and votes. I think you just need to tell maven where your repository is. Once the vote to release passes the incubator IPMC, you can just move the release artifacts from the staging repo to the real repo with a simple unix move command. Craig On Apr 8, 2007, at 4:42 PM, Marc Prud'hommeaux wrote: Craig- Yeah, we ran into this issue with the last release, where we kept re-building release candidates that were all labeled 0.9.6- incubating and were getting re-deployed to the official repository. It would be easy enough to deploy to an alternate repository for release approval (I think you could just use the - DaltDeploymentRepository flag), but then it would be a bit of a pain to move all the artifacts over once the release is approved. However, I agree that we need to fix the current problem of candidates being deployed to the official location, and that's probably the only way to do it. Also, FTR, we can sign the release by specifying the sign-release profile that manually runs GPG on the files (although we should move this to the official maven-gpg-plugin at some point). On Apr 8, 2007, at 3:07 PM, Craig L Russell wrote: Hi Mike, Something is wrong with the openjpa release process. Artifacts should not be uploaded to the repository until they are voted out of the project. Until they are ready, you should stage the proposed release, sign it, and after you're sure it's ready to go, call for a review on the dev list, and then call for a vote on the incubator general alias and dev list. You only need one checksum but need a gpg ascii armored signature. So you need the artifact and the artifact.asc (gpg signature) and artifact.md5 to be in the staging area. The sha1 is not needed. This should be part of the release process that's documented... Craig Begin forwarded message: From: Carlos Sanchez [EMAIL PROTECTED] Date: April 8, 2007 12:40:01 PM PDT To: [EMAIL PROTECTED] Cc: repository@apache.org Subject: Re: [repo] /www/people.apache.org/repo/m2-incubating- repository/ Reply-To: repository@apache.org please add PGP signatures, it's apache policy to sign all releases take a look at the latest maven parent pom on how to use the gpg plugin for automatic signing http://repo1.maven.org/maven2/org/apache/maven/maven-parent/5/ maven-parent-5.pom On 8 Apr 2007 08:17:08 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Repository changed == Repository: /www/people.apache.org/repo/m2-incubating-repository/ Added - [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating-site.xml [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating-site.xml.md5 [mikedd] org/apache/openjpa/openjpa/0.9.7-incubating/ openjpa-0.9.7-incubating-site.xml.sha1 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-lib/0.9.7-incubating/openjpa- lib-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom.md5 [mikedd] org/apache/openjpa/openjpa-kernel/0.9.7-incubating/ openjpa-kernel-0.9.7-incubating.pom.sha1 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/ openjpa-jdbc-0.9.7-incubating.jar [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/ openjpa-jdbc-0.9.7-incubating.jar.md5 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/ openjpa-jdbc-0.9.7-incubating.jar.sha1 [mikedd] org/apache/openjpa/openjpa-jdbc/0.9.7-incubating/ openjpa-jdbc-0.9.7-incubating.pom
Re: [repo] /www/people.apache.org/repo/m2-incubating-repository/
Hi Michael, It looks like the right people are involved in fixing this. Please do document the results of this discussion in the How To Make An OpenJPA Release. Craig On Apr 8, 2007, at 6:56 PM, Michael Dick wrote: Actually it looks like the link David sent us has the information. The release plugin provides a mechanism to deploy to a staging area. The catch is that migrating from the staging area to a production repository. A quick excerpt follows: Once the release is deemed fit for public consumption it can be transferred to a production repository where it will be available to all users. Currently the tools to do this are inconvenient so if you want to stage a release you can contact Jason and he'll show you how to do it. Otherwise you can release directly to a production repository. I'd assume the Jason in mentioned is Jason van Zyl (the only Jason on the team list for the maven-release plugin). I sent him an email asking about it. In any event the release plugin warrants a closer look. On 4/8/07, Craig L Russell [EMAIL PROTECTED] wrote: Hi Marc, I'll plead ignorance on this. I'd like to have some feedback from the maven incubator experts here. I'm copying the maven user list in case they can shed some light. Perhaps we need a new maven-incubator-release plugin that allows you to deploy to a ~mikedd repository that has no official standing and then copy the artifacts to the real repository after it's been approved by the incubator. It's hard for me to imagine, though, that the maven release plugin doesn't accommodate the need to deploy all of the release artifacts to a staging location for testing by the community, prior to making it generally available on the mirrors. It might be good for some of us openjpa folks to thoroughly examine the maven release plugin to see how they intended this to work... Craig On Apr 8, 2007, at 5:12 PM, Marc Prud'hommeaux wrote: Craig- I think that will generally work, but there is the issue of the maven-metadata.xml file in the parent directory (e.g., http:// people.apache.org/repo/m2-incubating-repository/org/apache/openjpa/ openjpa-project/maven-metadata.xml) that lists all of the releases. If you release to a different location and then manually move over the release subdirectories, the parent maven-metadata.xml won't automatically be updated. You could manually add the line to those files, but them the md5 and sha1 checksums would be wrong. I don't actually know who or what uses the maven-metadata.xml file, but that was one of the things that gave me pause during the last release about deploying to one location and then manually moving the approved artifacts over to the official repository. On Apr 8, 2007, at 5:03 PM, Craig L Russell wrote: Other projects use the people.apache.org/~mikedd/xxx as the staging repository while working through the release issues and votes. I think you just need to tell maven where your repository is. Once the vote to release passes the incubator IPMC, you can just move the release artifacts from the staging repo to the real repo with a simple unix move command. Craig On Apr 8, 2007, at 4:42 PM, Marc Prud'hommeaux wrote: Craig- Yeah, we ran into this issue with the last release, where we kept re-building release candidates that were all labeled 0.9.6- incubating and were getting re-deployed to the official repository. It would be easy enough to deploy to an alternate repository for release approval (I think you could just use the - DaltDeploymentRepository flag), but then it would be a bit of a pain to move all the artifacts over once the release is approved. However, I agree that we need to fix the current problem of candidates being deployed to the official location, and that's probably the only way to do it. Also, FTR, we can sign the release by specifying the sign- release profile that manually runs GPG on the files (although we should move this to the official maven-gpg-plugin at some point). On Apr 8, 2007, at 3:07 PM, Craig L Russell wrote: Hi Mike, Something is wrong with the openjpa release process. Artifacts should not be uploaded to the repository until they are voted out of the project. Until they are ready, you should stage the proposed release, sign it, and after you're sure it's ready to go, call for a review on the dev list, and then call for a vote on the incubator general alias and dev list. You only need one checksum but need a gpg ascii armored signature. So you need the artifact and the artifact.asc (gpg signature) and artifact.md5 to be in the staging area. The sha1 is not needed. This should be part of the release process that's documented... Craig Begin forwarded message: From: Carlos Sanchez [EMAIL PROTECTED] Date: April 8, 2007 12:40:01 PM PDT To: [EMAIL PROTECTED] Cc: repository@apache.org Subject: Re: [repo] /www/people.apache.org/repo/m2-incubating- repository/ Reply-To: repository
Re: why not an EntityExistsException was thrown?
Hi Wanyna, Whenever you query for entities, the result entities are put into your persistence context. So when you then try to persist another entity with the same identity the provider finds the query result in the persistence context and throws EntityExistsException. Craig On Apr 4, 2007, at 9:47 PM, wanyna wrote: Your explaination is clearly if I only show my test case 1. My test case 2, add a query before persist, then get EntityExistsException. The result of query hold some object no association with the object to persist. Why this time the object exists in persistence context? Craig L Russell wrote: If you look at the exception that is thrown from the database, it's a pretty general exception. The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL070403054930170' defined on 'BSC'. This might have been caused by a unique constraint, which would not be properly reported as EntityExistsException. Sadly, there is no standard SQL exception that specifically tells the provider (OpenJPA) that there was a primary key constraint violation. And you might also note that every database has its own way to report exceptions like this. What the EntityExistsException does is to report that there is already an entity with the same primary key in the persistence context. It doesn't report that there was a problem writing the entity to the database. If you're looking for better error reporting you can flush as part of the application-level persist operation. That way your application can catch a persistence exception that is caused either by persist or flush and report it as a problem persisting entity to your caller. But there is a down side to this. If you flush immediately after persist, the provider cannot optimize for performance. So it's a tradeoff that you need to make in your application. If you're keen on fixing this situation, I'd encourage you to volunteer to look at the databases and how they report unique and primary key constraint violations and see if it's possible to parse the sql code and report string to positively identify a primary key constraint violation. Craig On Apr 3, 2007, at 9:42 PM, wanyna wrote: I can't find EntityExistsException nested in RollbackExceptions. http://www.nabble.com/file/7646/exception.jpg Will exception mechanism be planned to improve? I think it's very important. Patrick Linskey wrote: Cool -- that explains it then. EM.commit() must throw RollbackExceptions (and org.apache.openjpa.persistence.RollbackException extends javax.persistence.RollbackException) when the transaction is rolled back during the course of the commit. If you get the nested exception from the RollbackException, I bet that it's instanceof EntityExistsException. Clearly, however, something is wonky with our exception printing algorithm. -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: wanyna [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 8:49 PM To: open-jpa-dev@incubator.apache.org Subject: RE: why not an EntityExistsException was thrown? actual class of the exception: class org.apache.openjpa.persistence.RollbackException 2|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.RollbackException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity ManagerImpl.java:417) at test.Main.main(Main.java:82) Caused by: 0|true|0.9.7-incubating-SNAPSHOT org.apache.openjpa.persistence.PersistenceException: The transaction has been rolled back. See the nested exceptions for details on the errors that occurred. at org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI mpl.java:2091) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java: 1836) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm pl.java:1754) at org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana gedRuntime.java:76) at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311) at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr oker.java:863) at org.apache.openjpa.persistence.EntityManagerImpl.commit
Re: why not an EntityExistsException was thrown?
If you look at the exception that is thrown from the database, it's a
pretty general exception.
The statement was aborted because it would have caused a duplicate
key value in a unique or primary key constraint or unique index
identified by 'SQL070403054930170' defined on 'BSC'.
This might have been caused by a unique constraint, which would not
be properly reported as EntityExistsException.
Sadly, there is no standard SQL exception that specifically tells the
provider (OpenJPA) that there was a primary key constraint violation.
And you might also note that every database has its own way to report
exceptions like this.
What the EntityExistsException does is to report that there is
already an entity with the same primary key in the persistence
context. It doesn't report that there was a problem writing the
entity to the database.
If you're looking for better error reporting you can flush as part of
the application-level persist operation. That way your application
can catch a persistence exception that is caused either by persist or
flush and report it as a problem persisting entity to your caller.
But there is a down side to this. If you flush immediately after
persist, the provider cannot optimize for performance. So it's a
tradeoff that you need to make in your application.
If you're keen on fixing this situation, I'd encourage you to
volunteer to look at the databases and how they report unique and
primary key constraint violations and see if it's possible to parse
the sql code and report string to positively identify a primary key
constraint violation.
Craig
On Apr 3, 2007, at 9:42 PM, wanyna wrote:
I can't find EntityExistsException nested in RollbackExceptions.
http://www.nabble.com/file/7646/exception.jpg
Will exception mechanism be planned to improve?
I think it's very important.
Patrick Linskey wrote:
Cool -- that explains it then.
EM.commit() must throw RollbackExceptions (and
org.apache.openjpa.persistence.RollbackException extends
javax.persistence.RollbackException) when the transaction is
rolled back
during the course of the commit.
If you get the nested exception from the RollbackException, I bet
that
it's instanceof EntityExistsException.
Clearly, however, something is wonky with our exception printing
algorithm.
-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: wanyna [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 03, 2007 8:49 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: why not an EntityExistsException was thrown?
actual class of the exception:
class org.apache.openjpa.persistence.RollbackException
2|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.RollbackException: The
transaction has been
rolled back. See the nested exceptions for details on the errors
that
occurred.
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:417)
at test.Main.main(Main.java:82)
Caused by: 0|true|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The
transaction has
been rolled back. See the nested exceptions for details on
the errors that
occurred.
at
org.apache.openjpa.kernel.BrokerImpl.newFlushException(BrokerI
mpl.java:2091)
at
org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1938)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1836)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerIm
pl.java:1754)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalMana
gedRuntime.java:76)
at
org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1311)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBr
oker.java:863)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(Entity
ManagerImpl.java:406)
... 1 more
Caused by: 0|false|0.9.7-incubating-SNAPSHOT
org.apache.openjpa.persistence.PersistenceException: The
statement was
aborted because it would have caused a duplicate key value in
a unique or
primary key constraint or unique index identified by
'SQL070403054930170'
defined on 'BSC'. {prepstmnt 15774883 INSERT INTO BSC (objid,
objname,
created, msc_name, objclass) VALUES (?, ?, ?, ?, ?) [params=
(long) 1,
(String) objname1, (Timestamp) 2006-05-04 18:13:51.0,
(String) objname0,
(String) bsc]} [code=-1, state=23505]
API or Query hints
I think any time we make a change to the external view of the project we need to have a discussion first. IMHO The JIRA process is pretty good for this kind of stuff. Someone proposes a feature with non-standardized external behavior and writes up what it should look like. Then we agree on the details and go for it. On this particular issue, I can see valid reasons for having an API that modifies the behavior of the query, but also understand why it might be good to mirror that behavior using query hints. But whichever way we go, we need to agree on the name and semantics of the API/property and how to pass it to the internal structures for execution. There is a danger in thinking of these as hints. As I would like to see it, the only down side to not recognizing a query hint is lower performance. But if your application doesn't behave correctly if the implementation can't do anything useful with the hint, then it's not a hint but an application requirement. And if the hint can only be executed in some specific databases, then we need to decide if we throw an exception if the database isn't capable. Craig On Apr 4, 2007, at 2:17 PM, Abe White wrote: ... for certain values of our. I think that it's important that we discuss API decisions as a group, as they have significant impacts on the OpenJPA product moving forward. This is especially important when there are dissenting views on a particular API decision, as is the case here. I agree with Patrick. API decisions need to be better thought out. For example, even if we decide as a group to use hints in this case, the names of the hints are important. The current hint names you chose are inconsistent with other OpenJPA hints in naming style and capitalization. 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. 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
Build failure with autoboxing
This is strange. Autoboxing turned off somehow? I must be doing
something wrong. Just checked out from the tip of trunk,
[INFO] Building OpenJPA JDBC
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 15 source files to /Users/clr/openjpa/openjpa/trunk/openjpa-
jdbc/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[242,31] incompatible types
found : boolean
required: java.lang.Boolean
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[249,29] operator ==
cannot be applied to java.lang.Boolean,boolean
/Users/clr/openjpa/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java:[253,34] operator ==
cannot be applied to java.lang.Boolean,boolean
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
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: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Tue Apr 3 12:34:59 2007
New Revision: 525252
URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -52,7 +52,7 @@
supportsLockingWithOrderClause = false;
supportsLockingWithOuterJoin = false;
supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;
requiresAutoCommitForMetaData = true;
requiresAliasForSubselect = true;
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
view=diffrev=525252r1=525251r2=525252
==
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -15,13 +15,15 @@
*/
package org.apache.openjpa.jdbc.sql;
+import java.lang.reflect.Method;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.util.Arrays;
-
+import java.util.StringTokenizer;
import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;
/**
* Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@
public String optimizeClause = optimize for;
public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int db2ISeriesV5R4AndLater = 5;
+ private static final String forUpdateOfClause=FOR UPDATE OF;
+private static final String withRSClause=WITH RS;
+private static final String withRRClause=WITH RR;
+private static final String useKeepUpdateLockClause= USE AND
KEEP UPDATE LOCKS;
+private static final String useKeepExclusiveLockClause=USE
AND KEEP EXCLUSIVE LOCKS;
+private static final String forReadOnlyClause = FOR READ ONLY;
public DB2Dictionary() {
platform = DB2;
validationSQL = SELECT DISTINCT(CURRENT TIMESTAMP) FROM
@@ -170,6 +183,18 @@
if (isJDBC3(metaData)) {
Re: svn commit: r525252 - in /incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql: AbstractDB2Dictionary.java DB2Dictionary.java
Never mind. I fixed it. I guess we still need to decide whether the
change goes in, but meantime it should compile...
Craig
On Apr 3, 2007, at 12:58 PM, Ritika Maheshwari wrote:
yes will do that
ritika
On 4/3/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi David,
The DB2Dictionary class doesn't compile with 1.4 due to autoboxing.
Can you please fix this?
Craig
public String getForUpdateClause(JDBCFetchConfiguration fetch,
boolean forUpdate) {
String isolationLevel = null;
Boolean updateClause = null;
DatabaseMetaData metaData = null;
StringBuffer forUpdateString = new StringBuffer();
try {
// Determine the update clause/isolationLevel the hint
// overrides the persistence.xml value
if (fetch != null fetch.getHint
(openjpa.hint.updateClause)
!=null )
updateClause = (Boolean)fetch.
getHint(openjpa.hint.updateClause);
else
updateClause = forUpdate;
=== here
if (fetch != null fetch.getHint
(openjpa.hint.isolationLevel)
!=null )
isolationLevel = (String)fetch.
getHint(openjpa.hint.isolationLevel);
else
isolationLevel = conf.getTransactionIsolation();
if (updateClause == false)
=== here
//This sql is not for update so add FOR Read Only
clause
forUpdateString.append( ).append(forReadOnlyClause)
.append( );
else if (updateClause == true)
{ === here
On Apr 3, 2007, at 12:35 PM, [EMAIL PROTECTED] wrote:
Author: wisneskid
Date: Tue Apr 3 12:34:59 2007
New Revision: 525252
URL: http://svn.apache.org/viewvc?view=revrev=525252
Log:
changes for JIRA OPENJPA-182
Modified:
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java
incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/AbstractDB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/
AbstractDB2Dictionary.java?view=diffrev=525252r1=525251r2=525252
=
=
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/AbstractDB2Dictionary.java Tue Apr 3 12:34:59
2007
@@ -52,7 +52,7 @@
supportsLockingWithOrderClause = false;
supportsLockingWithOuterJoin = false;
supportsLockingWithInnerJoin = false;
-supportsLockingWithSelectRange = false;
+supportsLockingWithSelectRange = true;
requiresAutoCommitForMetaData = true;
requiresAliasForSubselect = true;
Modified: incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/
apache/openjpa/jdbc/sql/DB2Dictionary.java
URL: http://svn.apache.org/viewvc/incubator/openjpa/trunk/openjpa-
jdbc/src/main/java/org/apache/openjpa/jdbc/sql/DB2Dictionary.java?
view=diffrev=525252r1=525251r2=525252
=
=
--- incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java (original)
+++ incubator/openjpa/trunk/openjpa-jdbc/src/main/java/org/apache/
openjpa/jdbc/sql/DB2Dictionary.java Tue Apr 3 12:34:59 2007
@@ -15,13 +15,15 @@
*/
package org.apache.openjpa.jdbc.sql;
+import java.lang.reflect.Method;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.SQLException;
import java.util.Arrays;
-
+import java.util.StringTokenizer;
import org.apache.openjpa.jdbc.kernel.JDBCFetchConfiguration;
import org.apache.openjpa.jdbc.schema.Sequence;
+import org.apache.openjpa.lib.log.Log;
/**
* Dictionary for IBM DB2 database.
@@ -31,7 +33,18 @@
public String optimizeClause = optimize for;
public String rowClause = row;
-
+private int db2ServerType = 0;
+private static final int db2ISeriesV5R3AndEarlier = 1;
+private static final int db2UDBV81OrEarlier = 2;
+private static final int db2ZOSV8x = 3;
+private static final int db2UDBV82AndLater = 4;
+private static final int db2ISeriesV5R4AndLater = 5;
+ private static final String forUpdateOfClause=FOR UPDATE
OF;
+private static final String withRSClause=WITH RS;
+private static final String withRRClause=WITH RR;
+private static final String useKeepUpdateLockClause= USE AND
KEEP UPDATE LOCKS;
+private static final String
Re: new site look
+1 Always looking for some creative talent to make web presence better. Craig On Apr 3, 2007, at 6:22 AM, Hiram Chirino wrote: Hi Guys, I'm the guy that put the original ActiveMQ design together. If you want I'll tweak it some more for you guys. Perhaps change the color scheme? Or do you just want a better integrated banner/logo? Once we get that done, perhaps you want a cool little software box like the ones that I made for: http://activemq.apache.org/activemq-411-release.html and http://geronimo.apache.org/downloads.html Regards, Hiram Marc Prud wrote: It's actually a pretty shameless (albeit attributed) ripoff of http:// activemq.apache.org/. Something with the previous templates broke recently (which itself was a shameless ripoff of http:// geronimo.apache.org/), so I figured it was a good opportunity to play around with the styles. I had been intending to clean it up and customize the schemes a little further, but, as usual, other events wound up taking priority. And, of course, we'll need a proper logo someday... and budding graphics designers out there? On Mar 27, 2007, at 10:54 AM, Eddie O'Neil wrote: +1 -- excellent work. Who knew! Eddie On 3/27/07, Patrick Linskey [EMAIL PROTECTED] wrote: Dude when did Marc figure out how to make pretty HTML? I love the new look. Thanks! -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. 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. -- View this message in context: http://www.nabble.com/new-site-look- tf3474563.html#a9810849 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
Fwd: [jira] Created: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
So, Jacek Laskowski is unable to send emails to the dev list. I don't recall seeing any moderation messages. Craig Begin forwarded message: BTW, I'm still unable to send emails to open-jpa-dev. Who should I contact to in order to fix it? Jacek Laskowski 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
JIRA powers
Hi Mike, You have god-like powers in Jira (group jira-administrator). You have the ability to do anything you want. Go to the administration page for OpenJPA. Click on manage versions; add a version. Craig On Apr 2, 2007, at 11:47 AM, Michael Dick wrote: On 4/2/07, Patrick Linskey [EMAIL PROTECTED] wrote: I have no problem adding this to the release. I was hoping to get OpenJPA-185 and OpenJPA-179 in as soon as I got commit access, and then start the release process. You should have commit access now. Is there anything else that we need to get in? If these are the only changes we need, I'll go ahead and start the release this afternoon. I think that the next step is to create an 0.9.8 goal within JIRA and move everything except those things we plan for 0.9.7 out to 0.9.8. Once we've done that and resolved all the 0.9.7 issues, we should be ready to build a release. How do I create a goal in JIRA? I don't seem to have access to do so, but I'm using the same ID that I had before I became a committer. It happens to be the same username as my Apache account, is there something I need to do to link them? I'm assuming that you've got the link to the release process that Marc put together, right? Yes, I've been going through that and the Apache documentation this morning. -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: Michael Dick [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 10:58 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared I have no problem adding this to the release. I was hoping to get OpenJPA-185 and OpenJPA-179 in as soon as I got commit access, and then start the release process. Is there anything else that we need to get in? If these are the only changes we need, I'll go ahead and start the release this afternoon. On 4/2/07, Patrick Linskey [EMAIL PROTECTED] wrote: I don't think that it's been cut yet. Mike: where do we stand on the 0.9.7 process? -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: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:23 AM To: open-jpa-dev@incubator.apache.org Subject: Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared Is this something we can put in 0.9.7 or has that been cut already? -dain On Apr 1, 2007, at 10:07 PM, Craig L Russell wrote: +1 to remove the restriction. As long as no parameters are missing, the query should be considered sufficient. Craig On Apr 1, 2007, at 9:30 AM, Marc Prud'hommeaux wrote: Seem fair enough to get rid of the description. I've opened https://issues.apache.org/jira/browse/OPENJPA-196 describing the issue. +1 from me to remove the restriction that there be exactly as many positional parameters declared as were assigned. On Mar 31, 2007, at 7:32 PM, Dain Sundstrom wrote: Actually, I think there is a bigger problem... Say I have a query like this: SELECT x FROM foo AS x WHERE foo.name = ?2 The org.apache.openjpa.kernel.QueryImpl.assertParameters (...) code assumes that if I have 1 parameter it is numbered ?1, but in EJB 2.1 this was not a requirement and there are certification tests that verify you are allowed to have unused parameters (e.g, in my example about ?1 and ?N where N2 are all not used). I couldn't find any text in the specification that says that all all positional parameters must be used in the query, but I did find text that say the EJB-QL 3.0 language is an extension of the EJB-QL 2.1 language: The Java
Re: composite ID w/ another composite ID as a field
Hi Jeff,
The pattern you use for Book/Library is
public class BookId implements Serializable {
private String name;
private String library;
The pattern you use for Page/Book is
public class PageId implements Serializable {
private int number;
private BookId book;
Have you tried
public class PageId implements Serializable {
private int number;
private String book;
Craig
On Apr 2, 2007, at 10:41 AM, jeff wrote:
say i have Library, Book, and Page classes. a Library has many
Books, and a Book has many Pages. A Library's ID is it's name
(simple). A Book's ID is a composite of it's name and it's owning
Library's name (bidirectional relationship). A Page's ID is a
composite of it's number and it's owning Book's ID, a BookID.
so, the PageId class starts like:
public class PageId implements Serializable {
private int number;
private BookId book;
the error i'm getting is at runtime ...
4|true|0.9.6-incubating
org.apache.openjpa.persistence.ArgumentException: Field
com.mycompany.book.Book.pages declares
com.mycompany.book.Page.book as its mapped-by field, but this
field is not a direct relation.
first, is what i'm trying to do even valid? i suspect it is not,
and the problem is that the fields of the ID class must be simple
types (i believe the spec demands that). although, the error
message is a little confusing so i am not sure.
it occurs to me that another way to achieve this would be to add
bookName and libraryName fields to the Page class, and add a
@PrePersist method that populates them by calling book.getName()
and book.getLibrary().getName(). but again this is messy because
that data is already in the table because of the bidirectional
relationship between the objects.
as always, i'm open to what are you an idiot? responses if i am
just going about trying to define the Library, Book, Page
relationship in an obtuse manner.
classes attached.
The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing.
package com.mycompany.book;
import java.io.Serializable;
import java.util.HashSet;
import java.util.Set;
import javax.persistence.CascadeType;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.IdClass;
import javax.persistence.ManyToOne;
import javax.persistence.OneToMany;
import javax.xml.bind.annotation.XmlAttribute;
import javax.xml.bind.annotation.XmlElement;
@IdClass(com.mycompany.book.BookId.class)
@Entity
public class Book implements Serializable {
@Id
@Column(
name=BOOK_NAME,
nullable = false
)
@XmlAttribute (required = true)
private String name;
@OneToMany(
cascade = CascadeType.ALL,
mappedBy = book
)
@XmlElement (name = page)
private SetPage pages = new HashSetPage();
@Id
@Column(
nullable = false
)
@ManyToOne (
cascade = CascadeType.ALL
)
private Library library;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public Page getPage(int n) {
for (Page p: pages) {
if (p.getNumber() == n) {
return p;
}
}
return null;
}
public void putPage(Page p) {
p.setBook(this);
pages.add(p);
}
public boolean equals(Object o) {
if (!(o instanceof Book)) {
return false;
}
Book other = (Book)o;
if (!getName().equals(other.getName())) {
return false;
}
return true;
}
public int hashCode() {
return getName().hashCode();
}
public Library getLibrary() {
return library;
}
public void setLibrary(Library library) {
this.library = library;
}
}
package com.mycompany.book;
import java.io.Serializable;
import javax.xml.bind.annotation.XmlTransient;
@XmlTransient
public class BookId implements Serializable {
private String name;
private String library;
public boolean equals(Object o) {
if (!(o instanceof BookId)) {
return false;
}
BookId other = (BookId)o;
if (!(getName().equals(other.getName( {
return false;
}
if (!getLibrary().equals(other.getLibrary())) {
return false;
}
return true;
}
public int hashCode() {
return getName().hashCode() * getLibrary().hashCode();
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getLibrary() {
return library;
}
public void setLibrary(String library) {
this.library = library;
}
}
package com.mycompany.book;
import java.io.Serializable;
import java.util.HashSet;
import java.util.Set;
import javax.persistence.CascadeType;
Re: [jira] Commented: (OPENJPA-197) @Version property doesn't ensure integrity when performing the merge operation
On Apr 2, 2007, at 11:18 AM, Abe White wrote: The spec says in 3.2.4.1 p. 52: Any Version columns used by the entity must be checked by the persistence runtime implementation during the merge operation and/or at flush or commit time. So, one could agree with Abe (the and/or is the key). Ok. Reading about it further, the spec says in 9.1.17 p. 178: The version is used to ensure integrity when performing the merge operation and for optimistic concurrency control. and there's nothing about flush/commit time. I'd call this a spec inconsistency. Sadly, when the spec talks about the same thing in multiple places, it's a source of human error if different places are inconsistent. You can send a clarification request to the spec feedback alias to confirm this. Also, verifying it against RI (which is alas TopLink Essentials) leads to the same conclusion and it seems that it's only OpenJPA who thinks differently. There's nothing special about the RI and its non-specified behavior. If the RI has a behavior that is not specified, then all that means is that you can write non-portable code with a dependency on the RI, just as you can write non-portable code with a dependency on OpenJPA. By the way, there is similar behavior for persist and delete, wherein deferred writes to the database are legal. Some implementations might flush immediately and detect duplicate/missing database instances but you cannot depend on this behavior either. Craig I wish I could give it a shot with other JPA providers than OpenJPA, TopLink and Hibernate (but would that change anything?). OK, then read the 4th paragraph of section 3.4.2. Also, note the fact that the TCK doesn't test for exception on merge. It doesn't matter how other implementations work, OpenJPA is completely correct according to the spec. 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. 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!
Re: 0.9.8 release
Hi Mike, On Apr 2, 2007, at 3:16 PM, Michael Dick wrote: Earlier today I created the 0.9.8 release in JIRA, and moved most of the open issues from 0.9.7 to 0.9.8. There's one open issue against 0.9.7 - OpenJPA-179 and I'll submit a fix for that later tonight (or move it to 0.9.8). Marc just committed the fix for OpenJPA-196, if there are any other issues that we need to include please move them back to 0.9.7. Besides the issues mentioned above I think we'll need to add a change log, building.txt (for the source archive) and a release notes file (I thought we had one, but I didn't see it - maybe I'm blind). I'll take a crack at those tonight as well. You should be able to get JIRA to create the skeleton of the release notes file. I'm not in front of it right now, but select the 0.9.7 release notes and it should give you a page that you can copy/paste into a file. Craig Assuming there aren't any other major issues, I'll go ahead and create the tags etc. tomorrow. Thanks, -- -Michael Dick 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!
Re: test - please disregard
Hi Jacek, I'm not moderating this list (yet). I'll let you know when to try again. Craig On Apr 2, 2007, at 1:00 PM, Jacek Laskowski wrote: Hopefully, it passes the gates. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl 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!
Re: Bad Derby query
Hi Dain,
I've seen this problem as well, with a different provider. The JPA
spec lead sez that ?1 IS NULL is not a portable JPAQL query, even
though some providers can generate SQL that some databases can
execute properly.
It might not be an easy issue for OpenJPA to fix. How easy is it for
you to generate a different query?
Craig
On Apr 2, 2007, at 5:27 PM, Dain Sundstrom wrote:
I have the following query:
SELECT a.alias FROM AliasBean AS a WHERE (a.alias IS NULL AND ?1
IS NULL) OR a.alias = ?1
Which works great when run against HSQLDB. When I switch the
database to Derby I get the following exception:
0|false|0.9.6-incubating
org.apache.openjpa.persistence.PersistenceException: Syntax error:
Encountered NULL at line 1, column 68. {SELECT t0.ALIAS FROM
ALIASEJB_TABLE t0 WHERE (t0.ALIAS IS NULL AND NULL IS NULL OR
t0.ALIAS IS NULL)} [code=2, state=42X01]
Now my code is setting the parameter to NULL but that should be
valid. Any idea what is going on? Also, I'm using 0.9.6 so is
this a known problem?
Thanks,
-dain
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!
Re: composite ID based on one side of a bidirectional one-many relationship
Hi Jeff,
The reason that this is done is so you can create an instance of the
PageId class without having a persistent (or detached) instance of
Book. The way it works now, if you have the id of the Book you can
construct an instance of the PageId by also supplying the page number.
If the types matched, you would need to have an instance of Book that
had the proper id field set before you could create an instance of
PageId. Which would mean that you might have to go to the database
twice to get a Page (once to get the Book and another to get the Page).
Another alternative if you want to avoid this confusion is to have
the Page mapped with a String bookId and int number. But that would
mean mapping the bookId column to both the Book relationship and to
the primary key. Which has its own set of issues.
Hope this makes sense. It was done deliberately.
Craig
On Mar 29, 2007, at 9:02 AM, jeff wrote:
thanks pinaki, now i get it :)
i must say though that these are confusing semantics. JPA wants me
to name the fields and mutators the same between the Page and
PageId class, but for them to be different types. imagine an object
model with two classes and two methods,
Foo.getBlah()
Bar.getBlah()
where Foo.getBlah() returns a String, and Bar.getBlah() returns an
int. not exactly intuitive to the user of such an API.
anyway :)
Pinaki Poddar [EMAIL PROTECTED] wrote: Page can have a primary key
field type of Book.
@IdClass(com.mycompany.book.PageId.class)
@Entity
public class Page {
@Id
int number;
@Id
@ManyToOne
private Book book;
}
public class PageId {
int number;
String book; // the type String must match the type of primary
key
used in Book.java
// the name of the variable book must match
the name of the variable in Page class.
}
public class Book {
@Id
String title;
}
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 4:35 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
hi,
abe closed this with the reasoning ...
the book field in the PageId class must be of type String to match
the
primary key field type of Book
was i mistaken when i understood you to say that Page could have a PK
field of type Book? if not, very sorry for all the confusion.
or were you just saying that open JPA allowed the PK field to be a
ManyToOne relationship?
p.s., it's issue #191
https://issues.apache.org/jira/browse/OPENJPA-191
Patrick Linskey
wrote: Yes, please do. It looks like
your code should work.
-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: jeff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 10:31 AM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
yes, i see the problem w/ the attached classes, and with a completely
different model where i am trying to accomplish the same thing.
should i file a bug? i can attach the test case there.
Patrick Linskey
wrote: Are you still
seeing that same problem with the code that you attached?
-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: jeff [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 27, 2007 1:42 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: composite ID based on one side of a bidirectional
one-many relationship
Patrick Linskey
wrote:
my ID class has a book field, and getters and setters for it
to match Page's book field. i wonder about the last line where it
says java.lang.String. that seems odd.
Can you post your Book and Page classes and the Page's IdClass?
attached. i keep trying to attach the entire project as a zip, but
apache's spam filter keeps dropping
Re: [VOTE] ArgumentException : More parameters were passed to execute() than were declared
+1 to remove the restriction. As long as no parameters are missing, the query should be considered sufficient. Craig On Apr 1, 2007, at 9:30 AM, Marc Prud'hommeaux wrote: Seem fair enough to get rid of the description. I've opened https:// issues.apache.org/jira/browse/OPENJPA-196 describing the issue. +1 from me to remove the restriction that there be exactly as many positional parameters declared as were assigned. On Mar 31, 2007, at 7:32 PM, Dain Sundstrom wrote: Actually, I think there is a bigger problem... Say I have a query like this: SELECT x FROM foo AS x WHERE foo.name = ?2 The org.apache.openjpa.kernel.QueryImpl.assertParameters(...) code assumes that if I have 1 parameter it is numbered ?1, but in EJB 2.1 this was not a requirement and there are certification tests that verify you are allowed to have unused parameters (e.g, in my example about ?1 and ?N where N2 are all not used). I couldn't find any text in the specification that says that all all positional parameters must be used in the query, but I did find text that say the EJB-QL 3.0 language is an extension of the EJB- QL 2.1 language: The Java Persistence query language is an extension of the Enterprise Java Beans query language, EJB QL, definedin[5]. So I think we must remove the extra-params check, but I would be happy with a don't check for extra-params flag. -dain On Mar 31, 2007, at 8:56 AM, Dain Sundstrom wrote: I'm working on a CMP 2 implementation that delegates to OpenJPA for persistence. I'm running into a problem where I get the following exception: org.apache.openjpa.persistence.ArgumentException : More parameters were passed to execute() than were declared: 4 parameters were specified for query execution, but only 2 parameters were declared in the query. In CMP you declare finder and select methods that have parameters which are passed into the query engine. You can have as many parameters as you like but are not required to use them all, but it appears that OpenJPA is enforcing a restriction where if the EJB-QL text only lists say 2 parameters and I set 4 I get the above exception. In order of perference: Is this spec required? If not, can we remove the check? Is there a way to disable the check? If so, how? Is there a way to determine the number of paramters a query takes? If so, I can change my code. Is there a way to get the ejbql text from a Query object? If so, I'll write a quick parser to determine number of queries myself. BTW, I'm currently using 0.9.6. Thanks, -dain 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: 0.9.7: build changes
On Mar 29, 2007, at 5:00 PM, Patrick Linskey wrote: Also, we might want to think about other bundlings, such as creating a single jar with all dependencies, I'm not all that keen on merging other project's jars into a single monolithic jar. I think people expect that component-oriented software is going to have various required and optional dependencies. I feel that monolithic jar bundling is more appropriate for an application, rather than for a component. I agree, but I know that others disagree, and I don't see any reason why one is necessarily more right than another. The cost to us of having a separate jar / distro seems low, and if it helps with adoption, I don't see a downside. I think that it does help adoption, and I don't see a downside either. Craig -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: Thursday, March 29, 2007 11:15 AM To: open-jpa-dev@incubator.apache.org Subject: Re: 0.9.7: build changes On Mar 28, 2007, at 7:54 PM, Patrick Linskey wrote: One thing that I would like to see happen prior to 0.9.7 is a change to the build artifacts so that we don't have '-project' or '-all' tacked onto the releases everywhere. I've opened https://issues.apache.org/jira/browse/OPENJPA-194 for this and assigned it to myself. Also, we might want to think about other bundlings, such as creating a single jar with all dependencies, I'm not all that keen on merging other project's jars into a single monolithic jar. I think people expect that component-oriented software is going to have various required and optional dependencies. I feel that monolithic jar bundling is more appropriate for an application, rather than for a component. or a download that includes docs. What do you guys think? The binary assembly is meant to include the docs (and did on past releases). I notice that they are absent from recent snapshots, though. I'll try to figure out why that is. -Patrick 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. 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: error building openjpa
By the way, I've seen failure to download dependencies causing build
failures that are resolved by running mvn multiple times. Each time
more of the dependencies get loaded but failures occur on subsequent
download attempts.
Maybe there should be a flag (default to true) that retries
continuously so you can at least tell that maven is trying to do
something. I'd rather wait an extra few minutes than try to debug why
a build failed. Are we paid to debug maven or to create value?
Craig
On Mar 28, 2007, at 2:20 PM, Pinaki Poddar wrote:
After the third execution of mvn package -Dtest=false
the target succeeded in creating the openjpa jars and zips.
The attendee mentioned that he had run svn update before building.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Patrick Linskey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 4:17 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: error building openjpa
What did that solution accomplish? It sounds like the .m2
repository was
out-of-date or something.
-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: Pinaki Poddar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 28, 2007 1:47 PM
To: open-jpa-dev@incubator.apache.org
Subject: RE: error building openjpa
Some of the attendees in a traininng course also experienced the same
error involving SurefireBooter.
The solution was to run mvn package -Dtest=false target few (3, in
this case) times.
Pinaki Poddar
BEA Systems
415.402.7317
-Original Message-
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On Behalf
Of Marc Prud'hommeaux
Sent: Wednesday, March 28, 2007 3:47 AM
To: open-jpa-dev@incubator.apache.org
Subject: Re: error building openjpa
That's a pretty weird error ... it looks more like Maven isn't
installed correctly. Are you able to build any other projects using
maven?
If you re-install maven and delete (or move aside) your ~/.m2/
directory, do you still get the error?
On Mar 28, 2007, at 12:24 AM, Xibin Zeng wrote:
Hi -
I just downloaded the source through svn and failed at building
openjpa. It failed at a NoClassDefFoundError for
SurefireBooter. What
did I miss?
This is the output:
$ mvn package -Dtest=false
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] OpenJPA
[INFO] OpenJPA Utilities
[INFO] OpenJPA Kernel
[INFO] OpenJPA JDBC
[INFO] OpenJPA XML Store
[INFO] OpenJPA Kernel 1.5
[INFO] OpenJPA JDBC 1.5
[INFO] OpenJPA JPA
[INFO] OpenJPA JPA JDBC
[INFO] OpenJPA Aggregate Jar
[INFO] OpenJPA Persistence Examples
[INFO] OpenJPA Distribution
[INFO] OpenJPA Integration Tests
[INFO] OpenJPA Examples Integration Tests
[INFO] OpenJPA JPA TCK Integration Tests
[INFO]
-
-
---
[INFO] Building OpenJPA
[INFO]task-segment: [package]
[INFO]
-
-
---
[INFO] [site:attach-descriptor]
[INFO]
-
-
---
[INFO] Building OpenJPA Utilities
[INFO]task-segment: [package]
[INFO]
-
-
---
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[antrun:run {execution: set subversion revision}] [INFO] Executing
tasks
[echo] Revision: 406193:523071
[INFO] Executed tasks
[INFO] [antrun:run {execution: delete sun.misc.Perf}]
[INFO] Executing
tasks [INFO] Executed tasks [INFO] [resources:testResources] [INFO]
Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date [INFO]
[surefire:test] [INFO] Surefire report directory:
c:\Development\openjpa\openjpa-lib\target\sure
orts
[INFO] Building jar: c:\DOCUME~1\xibin\LOCALS~1\Temp
\surefirebooter17408.jar
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/booter/SurefireBooter
Exception in thread main
[INFO]
-
-
--
[ERROR] BUILD FAILURE
[INFO]
-
-
--
[INFO] There are test failures.
[INFO]
-
-
