Re: [vfs] Google App Engine plug-in (GaeVFS)
On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or traditional Java servlet environments. Please let me know if you find this useful. This is kind of cool. My first thought was that it might be nice to include it in VFS itself, but after looking at http://code.google.com/appengine/terms.html I have my doubts that including this at Apache would be doable even as an optional component. However, I see no reason it couldn't be referenced on the web site and added to providers.xml to load if it is present. Unless, of course, someone else has a different opinion. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] Google App Engine plug-in (GaeVFS)
good job man ! was working on a similar thing but used email accounts as storage. really nice job! On Sun, May 31, 2009 at 9:32 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or traditional Java servlet environments. Please let me know if you find this useful. This is kind of cool. My first thought was that it might be nice to include it in VFS itself, but after looking at http://code.google.com/appengine/terms.html I have my doubts that including this at Apache would be doable even as an optional component. However, I see no reason it couldn't be referenced on the web site and added to providers.xml to load if it is present. Unless, of course, someone else has a different opinion. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
The distribution looks good. If you have to make a 3rd release candidate you may want to add a test on setConfig() and setFactory() in GenericKeyedObjectPool to improve the coverage. But don't hold the release for this. Emmanuel Bourg Phil Steitz a écrit : Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
AW: [vfs] Google App Engine plug-in (GaeVFS)
Hi! http://gaevfs.appspot.com/ cool stuff! This is kind of cool. My first thought was that it might be nice to include it in VFS itself, but after looking at http://code.google.com/appengine/terms.html I have my doubts that including this at Apache would be doable even as an optional component. However, I see no reason it couldn't be referenced on the web site and added to providers.xml to load if it is present. Unless, of course, someone else has a different opinion. There is no need to add this to VFS's providers.xml as a vfs plugin is able to provides its own vfs-providers.xml [1] which will be loaded by VFS then automatically. Ciao, Mario [1] http://commons.apache.org/vfs/api.html - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
Phil Steitz a écrit : Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ There are lots of checkstyle errors (463). However, most of them seem to be missing javadocs for private inner classes, so the missing javadocs are not really important. One error is related to an Apache header in CursorableLinkedList. Most probably some minor white space change or similar as the header is there. These problems are minor to me, so here is my +1. Luc The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [cli] New Parser available
Emmanuel, On Sat, 2009-05-30 at 23:38 +0200, Emmanuel Bourg wrote: James Ring a écrit : I think partial matching should be disabled by default. While a neat feature to reduce typing, this behaviour will probably come as a surprise to people because it is not found in most programs. Also, if an option is not completely specified, I know I'd like the program to crash rather than run but do something that I don't expect. I believe a lot a GNU tools implement the partial matching for the long options. For example ls --col is equivalent to ls --color. Same thing for mysql. But I haven't seen an application supporting the partial matching with long options using a single dash (java -ver doesn't work). I think I'll disable this case by default. There is a extremely crucial difference between this and the previous example, this one has -- and so must be handling long options, the earlier example was -ver. I would suggest that partial matching of long options with two hyphens can be on by default since there is no conflict. Partial matching of long options with single hyphen is much more problematic and so perhaps should be off by default. -- Russel. = Dr Russel Winder Partner xmpp: rus...@russel.org.uk Concertant LLPt: +44 20 7585 2200, +44 20 7193 9203 41 Buckmaster Road, f: +44 8700 516 084 voip: sip:russel.win...@ekiga.net London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder signature.asc Description: This is a digitally signed message part
[g...@vmgump]: Project commons-configuration-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-configuration-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 110 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-configuration-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven2 settings: [/srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven2 Settings in: /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/configuration/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/configuration/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-configuration-test/gump_work/build_apache-commons_commons-configuration-test.html Work Name: build_apache-commons_commons-configuration-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 49 secs Command Line: mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/configuration/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/configuration] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/apache-commons/configuration/target/commons-configuration-1.7-SNAPSHOT.jar - testAddNodesCopy(org.apache.commons.configuration.TestXMLConfiguration) testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSetRootAttribute(org.apache.commons.configuration.TestXMLConfiguration) testLoadAndSaveFromFile(org.apache.commons.configuration.TestXMLConfiguration) testSaveToURL(org.apache.commons.configuration.TestXMLConfiguration) testSaveToStream(org.apache.commons.configuration.TestXMLConfiguration) testAutoSave(org.apache.commons.configuration.TestXMLConfiguration) testSaveAttributes(org.apache.commons.configuration.TestXMLConfiguration) testCloneWithSave(org.apache.commons.configuration.TestXMLConfiguration) testEmptyElements(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithNullEncoding(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctype(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDoctypeIDs(org.apache.commons.configuration.TestXMLConfiguration) testSubsetWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testConfigurationsAtWithReload(org.apache.commons.configuration.TestXMLConfiguration) testGetKeysWithReload(org.apache.commons.configuration.TestXMLConfiguration) testSetTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testClearTextRootElement(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithSubSubnodeConfig(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabled(org.apache.commons.configuration.TestXMLConfiguration) testSaveDelimiterParsingDisabledAttrs(org.apache.commons.configuration.TestXMLConfiguration) testMultipleAttrValuesEscaped(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveWithReloadingStrategy(org.apache.commons.configuration.TestXMLConfiguration) testAutoSaveAddNodes(org.apache.commons.configuration.TestXMLConfiguration) testAddNodesAndSave(org.apache.commons.configuration.TestXMLConfiguration) testRegisterEntityId(org.apache.commons.configuration.TestXMLConfiguration) testSaveAfterCreateWithCopyConstructor(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootName(org.apache.commons.configuration.TestXMLConfiguration) testCopyRootNameNoDocument(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidation(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithValidationFailure(org.apache.commons.configuration.TestXMLConfiguration) Tests run: 1419, Failures: 0, Errors: 52, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO]
How to make a proposal
Hello, Suppose I wanted to make a proposal for something to be included in Commons, is there any particular way I should go about it, or should I just post it in this forum? Thanks, Chris -- View this message in context: http://www.nabble.com/How-to-make-a-proposal-tp23802008p23802008.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. == Not sure if this is a problem, but the RELEASE-NOTES etc refer to 1.5-RC2. The OSGI versions likewise include the RC2. Does that mean there will need to be another build and vote before release? The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ I used Last Changed Rev: 780316 The differences between the xml files have now disappeared; not sure what went wrong before. Also the only difference between the tag and the source archives are doap and release notes, as expected. Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. It failed again after a further 70 or so runs, so if it is a timing issue, the window must be very small. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. I'm just working through the Test class now, adding messages where the values are not obvious from the context. == Not sure if this is a problem, but the RELEASE-NOTES etc refer to 1.5-RC2. The OSGI versions likewise include the RC2. Does that mean there will need to be another build and vote before release? The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ I used Last Changed Rev: 780316 The differences between the xml files have now disappeared; not sure what went wrong before. Also the only difference between the tag and the source archives are doap and release notes, as expected. Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
Luc Maisonobe wrote: Phil Steitz a écrit : Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ There are lots of checkstyle errors (463). However, most of them seem to be missing javadocs for private inner classes, so the missing javadocs are not really important. Yes, I am personally OK with all of these. One error is related to an Apache header in CursorableLinkedList. Most probably some minor white space change or similar as the header is there. I will replace the header. That class was copied from [collections]. These problems are minor to me, so here is my +1. Luc The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-jelly-tags-fmt-test (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-fmt-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 2 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-fmt-test : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -WARNING- Overriding Maven properties: [/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties] -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/test-reports The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-fmt-test/gump_work/build_commons-jelly_commons-jelly-tags-fmt-test.html Work Name: build_commons-jelly_commons-jelly-tags-fmt-test (Type: Build) Work ended in a state of : Failed Elapsed: 9 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/fmt] CLASSPATH: /usr/lib/jvm/java-6-sun/lib/tools.jar:/srv/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/dist/lib/ant-swing.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/dist/lib/ant-apache-xalan2.jar:/srv/gump/public/workspace/ant/dist/lib/ant-trax.jar:/srv/gump/public/workspace/ant/dist/lib/ant-junit.jar:/srv/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/dist/lib/ant.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/beanutils/dist/commons-beanutils-31052009.jar:/srv/gump/pu blic/workspace/apache-commons/collections/build/commons-collections-31052009.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-31052009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-31052009.jar:/srv/gump/public/workspace/apache-commons/jexl/dist/commons-jexl-31052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-31052009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-31052009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-31052009.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/fmt/target/commons-jelly-tags- fmt-31052009.jar - [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] ... 11 more [junit] Root cause [junit] java.lang.NoClassDefFoundError: org/apache/tools/ant/Main [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.createProject(AntTagLibrary.java:128) [junit] at org.apache.commons.jelly.tags.ant.AntTagLibrary.getProject(AntTagLibrary.java:96) [junit] at org.apache.commons.jelly.tags.ant.AntTag.getAntProject(AntTag.java:310) [junit] at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:111) [junit] at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:267) [junit] at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:96) [junit] at org.apache.commons.jelly.tags.junit.CaseTag$1.runTest(CaseTag.java:60) [junit] [junit] [junit] Testcase:
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. It failed again after a further 70 or so runs, so if it is a timing issue, the window must be very small. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. I'm just working through the Test class now, adding messages where the values are not obvious from the context. The test failed again (after about 80 retries), and the visitCount for the two object was 1, whereas the expected value is 2 or 3. == Not sure if this is a problem, but the RELEASE-NOTES etc refer to 1.5-RC2. The OSGI versions likewise include the RC2. Does that mean there will need to be another build and vote before release? The tag is here: http://svn.apache.org/repos/asf/commons/proper/pool/tags/POOL_1_5_RC2/ I used Last Changed Rev: 780316 The differences between the xml files have now disappeared; not sure what went wrong before. Also the only difference between the tag and the source archives are doap and release notes, as expected. Thanks! Phil - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related. Could there be an issue with checking the age? I don't know how the ages are compared, but Java time resolution means multiple objects can be created in the same time slot. Not in this case. The test that is failing is not looking at age or evicting instances because of age. It is just validating idle objects in the pool (testWhileIdle = true). I will also look into this and see if I can get it to fail. Thanks again for your help on this. In case it helps, my DOS script for this is: call mvn compiler:testCompile echo Start testn.log :LOOP0 echo %DATE% %TIME% testn.log call mvn -Dtest=TestGenericKeyedObjectPool surefire:test goto LOOP%ERRORLEVEL% :LOOP1 type target\surefire-reports\*.txt testn.log call bell If you are not using Windows, it should be easy to change accordingly I have also just seen the following error: Running org.apache.commons.pool.impl.TestGenericKeyedObjectPool java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1139) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool$TestThread.run(TestGenericKeyedObjectPool.java:1339) at java.lang.Thread.run(Thread.java:534) I'm working on improving the reporting for this as well (at present the stack trace only goes to stderr; it would be useful if it was added to the surefire report). Thanks. That one could be timing. Pls go ahead and commit your
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
s...@apache.org wrote:
Thanks!
-for (int i = 0; i 4; i++) {
+for (int i = 0; i smallPrimes.length; i++) {
pool.setNumTestsPerEvictionRun(smallPrimes[i]);
-for (int j = 0; j 5; j++) {
+for (int j = 0; j 5; j++) { // TODO why 5?
No particular reason to choose 5 here - that is just the number of
random pool-generation-then-visiting iterations to perform. Could make
this a constant, but it is only used here.
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote:
s...@apache.org wrote:
Thanks!
-for (int i = 0; i 4; i++) {
+for (int i = 0; i smallPrimes.length; i++) {
pool.setNumTestsPerEvictionRun(smallPrimes[i]);
-for (int j = 0; j 5; j++) {
+for (int j = 0; j 5; j++) { // TODO why 5?
No particular reason to choose 5 here - that is just the number of random
pool-generation-then-visiting iterations to perform. Could make this a
constant, but it is only used here.
OK. I just wondered if it was related to 4==smallPrimes.length.
Perhaps it might be worth making it the outer loop?
Could then make it a variable, e.g. derived from a property, with
default value 5.
This could make the current debugging a bit easier, as we could use a
larger number.
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r780449 - /commons/proper/pool/trunk/src/test/org/apache/commons/pool/impl/TestGenericKeyedObjectPool.java
sebb wrote:
On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote:
s...@apache.org wrote:
Thanks!
-for (int i = 0; i 4; i++) {
+for (int i = 0; i smallPrimes.length; i++) {
pool.setNumTestsPerEvictionRun(smallPrimes[i]);
-for (int j = 0; j 5; j++) {
+for (int j = 0; j 5; j++) { // TODO why 5?
No particular reason to choose 5 here - that is just the number of random
pool-generation-then-visiting iterations to perform. Could make this a
constant, but it is only used here.
OK. I just wondered if it was related to 4==smallPrimes.length.
Perhaps it might be worth making it the outer loop?
Could then make it a variable, e.g. derived from a property, with
default value 5.
This could make the current debugging a bit easier, as we could use a
larger number.
+1
Phil
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: AW: [vfs] Google App Engine plug-in (GaeVFS)
There are two reasons for this: 1. GAE does not set the os.arch or os.version system properties. When Commons VFS initializes, it tries to do this (OS.java line 36), which throws NullPointerExceptions: * private* *static* *final* String *OS_ARCH* = System.*getProperty*( os.arch).toLowerCase(Locale.*US*); *private* *static* *final* String *OS_VERSION* = System.*getProperty*( os.version).toLowerCase(Locale.*US*); The GaeVFS class sets these system properties to avoid the NullPointerExceptions. 2. GAE does not allow background threads, which causes RuntimeExceptions if you try to initialize the default SoftRefFileCache. The GaeVFS class binds in the LRUFilesCache instead. All of this is documented within the GaeVFS source code. On Sun, May 31, 2009 at 10:48 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 31, 2009, at 2:44 AM, Mario Ivankovits wrote: There is no need to add this to VFS's providers.xml as a vfs plugin is able to provides its own vfs-providers.xml [1] which will be loaded by VFS then automatically. Thanks for reminding me. Then I wonder what the requirement that the application do FileSystemManager fsManager = GaeVFS.getManager(); is about.
Re: [vfs] Google App Engine plug-in (GaeVFS)
I would be very happy if you could reference it from the Commons VFS web site as a 3rd party plug-in. (Yes, the GaeVFS jar does contain a vfs-providers.xml configuration, so there's no need to add it to providers.xml). On Sun, May 31, 2009 at 2:32 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 30, 2009, at 2:55 PM, Vince Bonfanti wrote: The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or traditional Java servlet environments. Please let me know if you find this useful. This is kind of cool. My first thought was that it might be nice to include it in VFS itself, but after looking at http://code.google.com/appengine/terms.html I have my doubts that including this at Apache would be doable even as an optional component. However, I see no reason it couldn't be referenced on the web site and added to providers.xml to load if it is present. Unless, of course, someone else has a different opinion. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related. Could there be an issue with checking the age? I don't know how the ages are compared, but Java time resolution means multiple objects can be created in the same time slot. Not in this case. The test that is failing is not looking at age or evicting instances because of age. It is just validating idle objects in the pool (testWhileIdle = true). Could the evictor be visiting items in the wrong order? Perhaps favouring one object over another? I guess we'd need to validate all the counts before failing in order to find out. I will also look into this and see if I can get it to fail. Thanks again for your help on this. In case it helps, my DOS script for this is: call mvn
Re: [pool] 1.5-RC2 available for review
sebb wrote: On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related. Could there be an issue with checking the age? I don't know how the ages are compared, but Java time resolution means multiple objects can be created in the same time slot. Not in this case. The test that is failing is not looking at age or evicting instances because of age. It is just validating idle objects in the pool (testWhileIdle = true). Could the evictor be visiting items in the wrong order? Perhaps favouring one object over another? I guess we'd need to validate all the counts before failing in order to find out. I will also look into this and see if I can get it to fail. Thanks again for your help on this. In case it helps, my DOS script for this is: call mvn compiler:testCompile echo Start testn.log :LOOP0 echo %DATE% %TIME% testn.log call mvn -Dtest=TestGenericKeyedObjectPool surefire:test goto LOOP%ERRORLEVEL%
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related. Could there be an issue with checking the age? I don't know how the ages are compared, but Java time resolution means multiple objects can be created in the same time slot. Not in this case. The test that is failing is not looking at age or evicting instances because of age. It is just validating idle objects in the pool (testWhileIdle = true).
[POOL] 1.5-RC2 error in testEviction2
Just tried testing GKOP using Java 1.6: java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) and I got yet another different error: --- Test set: org.apache.commons.pool.impl.TestGenericKeyedObjectPool --- Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.703 sec FAILURE! testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.203 sec FAILURE! junit.framework.AssertionFailedError: Should be less than 1000 idle, found 1000 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) My system was probably quite busy at the time; I don't know if that is relevant or not. S/// - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related.
Re: [POOL] 1.5-RC2 error in testEviction2
sebb wrote: Just tried testing GKOP using Java 1.6: java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) and I got yet another different error: --- Test set: org.apache.commons.pool.impl.TestGenericKeyedObjectPool --- Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.703 sec FAILURE! testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.203 sec FAILURE! junit.framework.AssertionFailedError: Should be less than 1000 idle, found 1000 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) My system was probably quite busy at the time; I don't know if that is relevant or not. This is almost certainly a timing / clock resolution issue. Looks like the evictor did not kick off in time. Phil S/// - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: How to make a proposal
It kind of depends on what you're proposing... a new component? Probably start a discussion on this list. Enhancements to an existing component? Either start here on the list or open a JIRA issue. Does this help? -Matt --- On Sun, 5/31/09, chris0 technic...@gmail.com wrote: From: chris0 technic...@gmail.com Subject: How to make a proposal To: dev@commons.apache.org Date: Sunday, May 31, 2009, 5:57 AM Hello, Suppose I wanted to make a proposal for something to be included in Commons, is there any particular way I should go about it, or should I just post it in this forum? Thanks, Chris -- View this message in context: http://www.nabble.com/How-to-make-a-proposal-tp23802008p23802008.html Sent from the Commons - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [pool] 1.5-RC2 available for review
Phil Steitz wrote: sebb wrote: On 31/05/2009, sebb seb...@gmail.com wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: Thanks to all who provided feedback on RC1. Changes in RC2 * Fixed copyright date in NOTICE.txt * Restored development reports * Improved thread-safety and timing/reliability in GOP, GKOP tests - thanks, sebb! Unfortunately not enough, see below... * Added link to release javadoc in site.xml * Fixed xml errors in changes.xml * Added test for ErodingPerKeyKeyedObjectPool * Changed clirr comparison version from 1.3 to 1.4 * Added missing attributes to sources jar manifest The files are here: http://people.apache.org/~psteitz/commons-pool-1.5-RC2/ Source and binary archives agree with each other; hashes and sigs OK. Unfortunately, I got a new test failure with Java 1.4.2 and Maven: testEvictorVisiting(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 0.063 sec FAILURE! junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.checkEvictorVisiting(TestGenericKeyedObjectPool.java:947) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEvictorVisiting(TestGenericKeyedObjectPool.java:810) I tried re-running the test, and it was OK. Tried rebuild and retest - OK. As far as I can tell, that particular test does not use threads or timers as part of the test case, so that suggests that there might be a timing/threading issue in the main pool code. I'll try re-running the test case a few more times to see if I can get it to go wrong again. Also, clearly the failure message needs to be enhanced to show which of the following checks failed: assertTrue(visitCount = cycleCount visitCount = cycleCount + 1); Unfortunately a lot of the assertions fail to provide any details of what has gone wrong, which make debugging a lot harder. Thanks for finding and looking into this. Should not be happening. Sorry the tests in general and this one in particular are so cryptic. What this one is doing is verifying that the evictor visits idle instances in the keyed pools in oldest-to-youngest order and does not systematically miss any. What would be good to know at the time of the failure above is the values of the local variables visitCount, cycleCount and totalInstances. Probably also the values of the enclosing loop counts. It would perhaps be useful to not fail on the first such error, but only fail when all the objects have been checked, so one could see how many objects are not visited the expected number of times. What is going on in this part of the test is that there are three keyed pools randomly generated containing a total of totalInstances idle objects. The evictor is run a random number of times (between 10 and 60) and what we expect is that each instance in the combined pool will be visited either cycleCount or cycleCount +1 times, where cycleCount = (runs * pool.getNumTestsPerEvictionRun()) / totalInstances. That is the assertion that is failing. I don't see off the top of my head how this can be timing or concurrency-related. Could there be an issue with checking the age? I don't know how the ages are compared, but Java time resolution means multiple objects can be created in the same time slot. Not in this case. The test that is failing is not looking at age or evicting instances because of age. It is just validating idle objects in the pool (testWhileIdle = true). Could the evictor be visiting items in the wrong order? Perhaps favouring one object over another? I guess we'd need to validate all the counts before failing in order to find out. I will also look into this and see if I can get it to fail. Thanks again for your help on this. In case it helps, my DOS script for this is: call mvn compiler:testCompile echo Start testn.log :LOOP0 echo %DATE% %TIME% testn.log call mvn
Re: [POOL] 1.5-RC2 error in testEviction2
On 31/05/2009, Phil Steitz phil.ste...@gmail.com wrote: sebb wrote: Just tried testing GKOP using Java 1.6: java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03) Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing) and I got yet another different error: --- Test set: org.apache.commons.pool.impl.TestGenericKeyedObjectPool --- Tests run: 43, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 22.703 sec FAILURE! testEviction2(org.apache.commons.pool.impl.TestGenericKeyedObjectPool) Time elapsed: 1.203 sec FAILURE! junit.framework.AssertionFailedError: Should be less than 1000 idle, found 1000 at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.commons.pool.impl.TestGenericKeyedObjectPool.testEviction2(TestGenericKeyedObjectPool.java:453) My system was probably quite busy at the time; I don't know if that is relevant or not. This is almost certainly a timing / clock resolution issue. Looks like the evictor did not kick off in time. I've seen the same error on a quiet system twice now with Java 1.6.0 All the Thread.sleep() calls are enclosed in a try/catch block which ignores InterruptedException, so I suppose it's possible that the test did not wait as long as expected. Since the sleep is an essential part of the test, perhaps the try/catch blocks should be removed, so the test will fail if the sleep fails? Phil S/// - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [vfs] Google App Engine plug-in (GaeVFS)
Great work man.!!! On Sun, May 31, 2009 at 3:25 AM, Vince Bonfanti vbonfa...@gmail.com wrote: The first public release (0.1) of GaeVFS is now available: http://gaevfs.appspot.com/ GaeVFS is a plug-in for Apache Commons VFS that implements a virtual file system on top of the Google App Engine for Java (GAE) datastore. It provides a writeable file system for GAE, since GAE does not allow writing to the local file system. GaeVFS is licensed under the Apache License, Version 2.0. GaeVFS includes a servlet (GaeVfsServlet) that allows you to: - upload files into GaeVFS - serve files from GaeVFS - (optionally) perform GaeVFS directory listings The goal of GaeVFS is to provide a portability layer that allows you to write application code to access the file system (both reads and writes) that runs unmodified in either the GAE or traditional Java servlet environments. Please let me know if you find this useful. -- by DILEEP KUMAR.MANDAPAM
Re: Proposal - A Very Simple API for Reading Simple XML Data
This should have gone to the dev list. On May 31, 2009, at 10:33 PM, Ralph Goers wrote: On May 31, 2009, at 9:24 AM, chris0 wrote: Hello, I'm making this proposal because I couldn't find a good solution to a problem that I recently had. What I wanted to do was to configure an application with a simple XML file, something along the lines of: config titletest/title version major=1 minor=2/ roles role name=admin/ role name=user/ /roles users user name=joe password=pass role=admin/ user name=harry password=secret role=user/ /users /config So the point is that it's really a very simple bit of XML data and what I wanted was a nice easy way to read it in. The current options seem to be SAX, DOM or JAXB. Why not just use Commons Configuration and do: HierarchicalConfiguration config = new XMLConfiguration(config.xml); String title = config.getString(title); int majorVersion = config.getInt(versi...@major]); etc. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
