Re: [pool] 1.x and TestGenericObjectPoolClassLoaders
On Thu, May 16, 2013 at 6:30 PM, Mark Thomas ma...@apache.org wrote: On 16/05/2013 20:58, Gary Gregory wrote: TestGenericObjectPoolClassLoaders (1) org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders) junit.framework.AssertionFailedError: Wrong number of idle objects in pool1 expected:1 but was:0 snip/ at org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders.testContextClassLoader(TestGenericObjectPoolClassLoaders.java:46) snip/ Looking at line 46 of the test, it is possible that it could fail depending on the execution timing. Maybe try increasing the Thread.sleep() ? I am glad it works on your end. It fails no matter what I change the numbers to, for example: pool1.setTimeBetweenEvictionRunsMillis(20); Thread.sleep(5000); or: pool1.setTimeBetweenEvictionRunsMillis(1000); Thread.sleep(5000); arg :( I makes it hard to cut an RC! Gary This fails for me from Eclipse and Maven: Maven home: C:\Java\apache-maven-3.0.5\bin\.. I don't use Maven. Java version: 1.7.0_21, vendor: Oracle Corporation Same version, 64 bit version. Java home: C:\Program Files\Java\jdk1.7.0_21\jre Different install location - that shouldn't matter. Default locale: en_US, platform encoding: Cp1252 en_GB, Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Same apart from Windows Server 2008 R2 Pretty similar platforms. Best guess is a timing issue. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [pool] 1.x and TestGenericObjectPoolClassLoaders
On 17/05/2013 13:51, Gary Gregory wrote: On Thu, May 16, 2013 at 6:30 PM, Mark Thomas ma...@apache.org wrote: On 16/05/2013 20:58, Gary Gregory wrote: TestGenericObjectPoolClassLoaders (1) org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders) junit.framework.AssertionFailedError: Wrong number of idle objects in pool1 expected:1 but was:0 snip/ at org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders.testContextClassLoader(TestGenericObjectPoolClassLoaders.java:46) snip/ Looking at line 46 of the test, it is possible that it could fail depending on the execution timing. Maybe try increasing the Thread.sleep() ? I am glad it works on your end. It fails no matter what I change the numbers to, for example: OK. That makes a timing issue unlikely. pool1.setTimeBetweenEvictionRunsMillis(20); Thread.sleep(5000); or: pool1.setTimeBetweenEvictionRunsMillis(1000); Thread.sleep(5000); arg :( I makes it hard to cut an RC! Indeed. I'd suggest it is time to step through that test case with the debugger in Eclipse and figure out why the object isn't being created. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [IO] converting streams to buffered versions - rename asBufferedxxxx to buffer?`
On 16 May 2013 18:25, Dave Brosius dbros...@mebigfatguy.com wrote: or ByteArrayInput/OutputStream On 05/16/2013 01:13 PM, Jörg Schaible wrote: sebb wrote: The issue https://issues.apache.org/jira/browse/IO-330 added 4 methods: public static Buffered asBuffered(final ) where = InputStream, OutputStream, Reader, Writer I just noticed that https://issues.apache.org/jira/browse/IO-233 suggests overloaded methods called buffer instead: public static Buffered buffer(final ) This is quite a lot easier to type, so I propose to rename the methods (and link the JIRAs) unless there are objections. +1 However, I'd wrap the provided stream/reader/writer only, if it is not already a (derived) buffered implementation. That's what the asBuffered methods already do - they buffer the IO channel if not already buffered. Cheers, Jörg - 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: [IO] converting streams to buffered versions - rename asBufferedxxxx to buffer?`
On 16 May 2013 18:25, Dave Brosius dbros...@mebigfatguy.com wrote: or ByteArrayInput/OutputStream Would adding buffering help for those? If so. please raise a JIRA enhancement. On 05/16/2013 01:13 PM, Jörg Schaible wrote: sebb wrote: The issue https://issues.apache.org/jira/browse/IO-330 added 4 methods: public static Buffered asBuffered(final ) where = InputStream, OutputStream, Reader, Writer I just noticed that https://issues.apache.org/jira/browse/IO-233 suggests overloaded methods called buffer instead: public static Buffered buffer(final ) This is quite a lot easier to type, so I propose to rename the methods (and link the JIRAs) unless there are objections. +1 However, I'd wrap the provided stream/reader/writer only, if it is not already a (derived) buffered implementation. Cheers, Jörg - 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: [pool] 1.x and TestGenericObjectPoolClassLoaders
Hello, TL;DR: looks like there is an ignored exception that occurs when the test factory CustomClassLoaderObjectFactory tries to load a not existing resource. Test files 'test1' and 'test2' that are not processed by Maven (branch 1.x has a not-maven-default directory structure). This way, no new objects are created/added to the pool and the test fails. --- FWIU, in TestGenericObjectPoolClassLoaders.java the testContextClassLoader() test method creates custom class loaders (CustomClassLoader) and custom class loader object factories (CustomClassLoaderObjectFactory). These factories are created with a number and the makeObject() method returns an URL to a resource test + n. In the test package, there are two files, test1 and test2 that were supposed to be used in the test. However, it looks like during test execution these files are not included by Maven (probably because the 1.x branch has a custom directory structure). Thus, the CustomClassLoaderObjectFactory#makeObject() method returns null. When the GenericObjectPool tries to create a new object (using that factory) an exception is raised, but ignored (see GenericObjectPool, line 1801). And in the end no new objects are added to the pool and the test fails. I think we could fix it by changing the pom.xml to include these two files or by dropping these files and creating some other dummy URL for tests. Here's a patch that worked for me [1] (sorry, going to a meeting and couldn't attach a decent patch right now). Just my 0.02 cents, hope that helps. Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 10:51:28-0300) Maven home: /opt/java/apache-maven-3.0.5 Java version: 1.6.0_43, vendor: Sun Microsystems Inc. Java home: /opt/java/jdk1.6.0_43/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.8.0-21-generic, arch: amd64, family: unix Cheers, Bruno [1] https://gist.github.com/kinow/5600147 Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com --- Em sex, 17/5/13, Mark Thomas ma...@apache.org escreveu: De: Mark Thomas ma...@apache.org Assunto: Re: [pool] 1.x and TestGenericObjectPoolClassLoaders Para: Commons Developers List dev@commons.apache.org Data: Sexta-feira, 17 de Maio de 2013, 10:03 On 17/05/2013 13:51, Gary Gregory wrote: On Thu, May 16, 2013 at 6:30 PM, Mark Thomas ma...@apache.org wrote: On 16/05/2013 20:58, Gary Gregory wrote: TestGenericObjectPoolClassLoaders (1) org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders) junit.framework.AssertionFailedError: Wrong number of idle objects in pool1 expected:1 but was:0 snip/ at org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders.testContextClassLoader(TestGenericObjectPoolClassLoaders.java:46) snip/ Looking at line 46 of the test, it is possible that it could fail depending on the execution timing. Maybe try increasing the Thread.sleep() ? I am glad it works on your end. It fails no matter what I change the numbers to, for example: OK. That makes a timing issue unlikely. pool1.setTimeBetweenEvictionRunsMillis(20); Thread.sleep(5000); or: pool1.setTimeBetweenEvictionRunsMillis(1000); Thread.sleep(5000); arg :( I makes it hard to cut an RC! Indeed. I'd suggest it is time to step through that test case with the debugger in Eclipse and figure out why the object isn't being created. Mark - 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.x and TestGenericObjectPoolClassLoaders
Yep, it's a resource problem. I found a simple way to fix it. see revision 1483916. Thank you for digging in. Gary On Fri, May 17, 2013 at 12:18 PM, Bruno P. Kinoshita brunodepau...@yahoo.com.br wrote: Hello, TL;DR: looks like there is an ignored exception that occurs when the test factory CustomClassLoaderObjectFactory tries to load a not existing resource. Test files 'test1' and 'test2' that are not processed by Maven (branch 1.x has a not-maven-default directory structure). This way, no new objects are created/added to the pool and the test fails. --- FWIU, in TestGenericObjectPoolClassLoaders.java the testContextClassLoader() test method creates custom class loaders (CustomClassLoader) and custom class loader object factories (CustomClassLoaderObjectFactory). These factories are created with a number and the makeObject() method returns an URL to a resource test + n. In the test package, there are two files, test1 and test2 that were supposed to be used in the test. However, it looks like during test execution these files are not included by Maven (probably because the 1.x branch has a custom directory structure). Thus, the CustomClassLoaderObjectFactory#makeObject() method returns null. When the GenericObjectPool tries to create a new object (using that factory) an exception is raised, but ignored (see GenericObjectPool, line 1801). And in the end no new objects are added to the pool and the test fails. I think we could fix it by changing the pom.xml to include these two files or by dropping these files and creating some other dummy URL for tests. Here's a patch that worked for me [1] (sorry, going to a meeting and couldn't attach a decent patch right now). Just my 0.02 cents, hope that helps. Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19 10:51:28-0300) Maven home: /opt/java/apache-maven-3.0.5 Java version: 1.6.0_43, vendor: Sun Microsystems Inc. Java home: /opt/java/jdk1.6.0_43/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux, version: 3.8.0-21-generic, arch: amd64, family: unix Cheers, Bruno [1] https://gist.github.com/kinow/5600147 Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com --- Em sex, 17/5/13, Mark Thomas ma...@apache.org escreveu: De: Mark Thomas ma...@apache.org Assunto: Re: [pool] 1.x and TestGenericObjectPoolClassLoaders Para: Commons Developers List dev@commons.apache.org Data: Sexta-feira, 17 de Maio de 2013, 10:03 On 17/05/2013 13:51, Gary Gregory wrote: On Thu, May 16, 2013 at 6:30 PM, Mark Thomas ma...@apache.org wrote: On 16/05/2013 20:58, Gary Gregory wrote: TestGenericObjectPoolClassLoaders (1) org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders testContextClassLoader(org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders) junit.framework.AssertionFailedError: Wrong number of idle objects in pool1 expected:1 but was:0 snip/ at org.apache.commons.pool.impl.TestGenericObjectPoolClassLoaders.testContextClassLoader(TestGenericObjectPoolClassLoaders.java:46) snip/ Looking at line 46 of the test, it is possible that it could fail depending on the execution timing. Maybe try increasing the Thread.sleep() ? I am glad it works on your end. It fails no matter what I change the numbers to, for example: OK. That makes a timing issue unlikely. pool1.setTimeBetweenEvictionRunsMillis(20); Thread.sleep(5000); or: pool1.setTimeBetweenEvictionRunsMillis(1000); Thread.sleep(5000); arg :( I makes it hard to cut an RC! Indeed. I'd suggest it is time to step through that test case with the debugger in Eclipse and figure out why the object isn't being created. Mark - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
[ALL] maven-scm-publish-plugin and ignorePathToDeletejavadocs**/ignorePathToDelete
Hi All: I see in several components: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId configuration ignorePathsToDelete ignorePathToDeletejavadocs**/ignorePathToDelete /ignorePathsToDelete /configuration /plugin Should that be in the parent? If so, can you then ADD ignorePathsToDelete, like Commons Logging needs to do? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] maven-scm-publish-plugin and ignorePathToDeletejavadocs**/ignorePathToDelete
On 17 May 2013 18:22, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I see in several components: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId configuration ignorePathsToDelete ignorePathToDeletejavadocs**/ignorePathToDelete /ignorePathsToDelete /configuration /plugin Should that be in the parent? Does it apply to all (or almost all) components? If so, can you then ADD ignorePathsToDelete, like Commons Logging needs to do? Same answer as for RAT excludes; see http://blog.sonatype.com/people/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/ Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] maven-scm-publish-plugin and ignorePathToDeletejavadocs**/ignorePathToDelete
On Fri, May 17, 2013 at 1:26 PM, sebb seb...@gmail.com wrote: On 17 May 2013 18:22, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I see in several components: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId configuration ignorePathsToDelete ignorePathToDeletejavadocs**/ignorePathToDelete /ignorePathsToDelete /configuration /plugin Should that be in the parent? Does it apply to all (or almost all) components? Well, all components except commons-parent have Javadocs generated AFAIK. Gary If so, can you then ADD ignorePathsToDelete, like Commons Logging needs to do? Same answer as for RAT excludes; see http://blog.sonatype.com/people/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/ Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
Re: [ALL] maven-scm-publish-plugin and ignorePathToDeletejavadocs**/ignorePathToDelete
On 17 May 2013 18:33, Gary Gregory garydgreg...@gmail.com wrote: On Fri, May 17, 2013 at 1:26 PM, sebb seb...@gmail.com wrote: On 17 May 2013 18:22, Gary Gregory garydgreg...@gmail.com wrote: Hi All: I see in several components: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-scm-publish-plugin/artifactId configuration ignorePathsToDelete ignorePathToDeletejavadocs**/ignorePathToDelete /ignorePathsToDelete /configuration /plugin Should that be in the parent? Does it apply to all (or almost all) components? Well, all components except commons-parent have Javadocs generated AFAIK. And are they all in the same location? Also I would expect the location to be defined by a Maven property which defaults to where the javadoc plugin creates the files Gary If so, can you then ADD ignorePathsToDelete, like Commons Logging needs to do? Same answer as for RAT excludes; see http://blog.sonatype.com/people/2011/01/maven-how-to-merging-plugin-configuration-in-complex-projects/ Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [VOTE] Release of Commons Logging 1.1.3 based on RC2
FWIW, I did some testing of the binaries with an existing application using Commons VFS and Apache Pivot and all appears to be good. +1 ~Roger Whitcomb Apache Pivot PMC Chair -Original Message- From: Thomas Neidhart [mailto:thomas.neidh...@gmail.com] Sent: Thursday, May 16, 2013 1:28 PM To: Commons Developers List Subject: [VOTE] Release of Commons Logging 1.1.3 based on RC2 Hi, I'd like to call a vote for releasing Commons Logging 1.1.3 based on RC2. This release candidate has the following changes compared to RC1: * fix ant build script: version, dependencies, created artifacts The files: The artifacts are deployed to Nexus: https://repository.apache.org/content/repositories/orgapachecommons-006/ commons-logging/commons-logging/1.1.3/ Distribution files: https://dist.apache.org/repos/dist/dev/commons/logging/ The tag: https://svn.apache.org/repos/asf/commons/proper/logging/tags/LOGGING_1_1 _3_RC2/ The site: http://people.apache.org/builds/commons/logging/1.1.3/RC2/ Additional Notes: o the download page and api links to older releases only work on the published site and will be corrected after release. Please take a look at the commons-logging-1.1.3 artifacts and vote! [ ] +1 release it. [ ] +0 go ahead; I don't care. [ ] -0 there are a few minor glitches: ... [ ] -1 no, do not release it because ... Vote will remain open for at least 72 hours. Thanks in advance, Thomas - 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