Re: svn commit: r891572 - in /commons/proper/lang/trunk/src: java/org/apache/commons/lang3/time/DateUtils.java test/org/apache/commons/lang3/time/DateUtilsTest.java
Unless we implement FastDateFormat.parseObject fully, I couldn't see
any good paths here and chose the least bad path. I think this change
helps the common use case without incurring any pain on the abnormal
use case (apart from the two endsWith checks). Opinions welcome as
this didn't feel beautiful.
On Wed, Dec 16, 2009 at 11:21 PM, wrote:
> Author: bayard
> Date: Thu Dec 17 07:21:25 2009
> New Revision: 891572
>
> URL: http://svn.apache.org/viewvc?rev=891572&view=rev
> Log:
> Applying 'fix' for LANG-530. DateUtils.parseDate now protects the common use
> case of FastDateFormat ZZ output, namely ZZ on the end of the pattern, from
> being passed to SimpleDateFormat as is. Use of ZZ elsewhere in the pattern
> isn't protected and will want to consider emulating the String changes made
> in this patch.
>
> Modified:
>
> commons/proper/lang/trunk/src/java/org/apache/commons/lang3/time/DateUtils.java
>
> commons/proper/lang/trunk/src/test/org/apache/commons/lang3/time/DateUtilsTest.java
>
> Modified:
> commons/proper/lang/trunk/src/java/org/apache/commons/lang3/time/DateUtils.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/java/org/apache/commons/lang3/time/DateUtils.java?rev=891572&r1=891571&r2=891572&view=diff
> ==
> ---
> commons/proper/lang/trunk/src/java/org/apache/commons/lang3/time/DateUtils.java
> (original)
> +++
> commons/proper/lang/trunk/src/java/org/apache/commons/lang3/time/DateUtils.java
> Thu Dec 17 07:21:25 2009
> @@ -290,14 +290,29 @@
> SimpleDateFormat parser = null;
> ParsePosition pos = new ParsePosition(0);
> for (int i = 0; i < parsePatterns.length; i++) {
> +
> + String pattern = parsePatterns[i];
> +
> + // LANG-530 - need to make sure 'ZZ' output doesn't get passed
> to SimpleDateFormat
> + if (parsePatterns[i].endsWith("ZZ")) {
> + pattern = pattern.substring(0, pattern.length() - 1);
> + }
> +
> if (i == 0) {
> - parser = new SimpleDateFormat(parsePatterns[0]);
> + parser = new SimpleDateFormat(pattern);
> } else {
> - parser.applyPattern(parsePatterns[i]); // cannot be null if
> i != 0
> + parser.applyPattern(pattern); // cannot be null if i != 0
> }
> pos.setIndex(0);
> - Date date = parser.parse(str, pos);
> - if (date != null && pos.getIndex() == str.length()) {
> +
> + String str2 = str;
> + // LANG-530 - need to make sure 'ZZ' output doesn't hit
> SimpleDateFormat as it will ParseException
> + if (parsePatterns[i].endsWith("ZZ")) {
> + str2 = str.replaceAll("([-+][0-9][0-9]):([0-9][0-9])$",
> "$1$2");
> + }
> +
> + Date date = parser.parse(str2, pos);
> + if (date != null && pos.getIndex() == str2.length()) {
> return date;
> }
> }
>
> Modified:
> commons/proper/lang/trunk/src/test/org/apache/commons/lang3/time/DateUtilsTest.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/test/org/apache/commons/lang3/time/DateUtilsTest.java?rev=891572&r1=891571&r2=891572&view=diff
> ==
> ---
> commons/proper/lang/trunk/src/test/org/apache/commons/lang3/time/DateUtilsTest.java
> (original)
> +++
> commons/proper/lang/trunk/src/test/org/apache/commons/lang3/time/DateUtilsTest.java
> Thu Dec 17 07:21:25 2009
> @@ -1156,6 +1156,15 @@
> // restore default time zone
> TimeZone.setDefault(defaultZone);
> }
> +
> + // http://issues.apache.org/jira/browse/LANG-520
> + public void testLang520() throws ParseException {
> + Date d = new Date();
> + String isoDateStr =
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.format(d);
> + Date d2 = DateUtils.parseDate(isoDateStr, new String[] {
> DateFormatUtils.ISO_DATETIME_TIME_ZONE_FORMAT.getPattern() });
> + // the format loses milliseconds so have to reintroduce them
> + assertEquals("Date not equal to itself ISO formatted and parsed",
> d.getTime(), d2.getTime() + d.getTime() % 1000);
> + }
>
> /**
> * Tests various values with the ceiling method
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Jörg Schaible wrote: > Phil Steitz wrote: > >> Phil Steitz wrote: >>> Jörg Schaible wrote: Jörg Schaible wrote: > Jörg Schaible wrote: > >> Hi Phil, >> >> Phil Steitz wrote: >> >> [snip] >> > 1.4 (JDBC 4) version: > http://people.apache.org/~psteitz/dbcp-1.4-rc1 > http://people.apache.org/~psteitz/dbcp-1.4-rc1/site > http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven > > http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with IBM 1.6.0.6: == %< > --- Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource > --- Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 sec <<< FAILURE! > testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) Time elapsed: 0.066 sec <<< FAILURE! junit.framework.AssertionFailedError: Expecting SQLException - XAResources orphaned at junit.framework.Assert.fail(Assert.java:47) at > org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) >>> I could use some help debugging this one. I do not have the JDK to >>> test with and the failure makes no sense to me. Does it happen >>> every time? >> It seems it was caused by a difference in the WeakReference >> implementation. The DelegactingConnection returned the same hashCode >> than the inner connection. However, both instances were kept in the >> registry in xaReference (a WeakMap). >>> Need to figure out why that is happening. This could be a test bug. >>> The connection should only be added once to the registry. >>> >>> After using a distinguishable hashCode, the >> test succeeds also with IBM JDK. >> >> Additionally I dropped the JDK 1.4 deps from the POM. >>> That is OK for the trunk POM. Thanks. >> I'll look into DBCP 1.3 ASAP - it got too late now ;-) > Guess it was really too late yesterday. While > TestBasicManagedDataSource works now, my change borked the > TestManagedDataSourceInTx tests (interestingly 33 with Sun JDK, but > only 28 with IBM). Basically my change broke the contract with hashCode > that should be the same for "equal" objects. > > Question is now, what to do. If we revert the change, the IBM JDK is > broken and it fails to release the transactions. Otherwise we have to > change additionally the equals method, so that a DelegatingConnection > is not equal to the wrapped Connection. However, this may case even > more hick-ups. I've reverted the hashCode change for now that brings back the IBM JDK problem. :-/ >>> Thanks, Jorg. I think changing equals is not a good idea. Thanks >>> again for your help. >>> >> This is a test bug. The test is manually registering the connection >> after the LocalXAConnectionFactory has already done it. Fixing >> now. This should eliminate the problem. > > The funny thing is that on Sun JDK registering the ManagedConnection itself > will update the entry in the WeakHashMap of the delegated connection. On IBM > JDK a new entry is created in the map. Later on is the ManagedConnection > removed, but the lookup will now return the delegated connection (may be > because of equality of the connection and its hash code when it is used as > key. I don't know why the JDK behavior is different, but you have it right - the test code was registering the ManagedConnection returned by the ManagedDataSource whereas the LocalXAConnectionFactory registers the DelegatingConnection that the ManagedConnection wraps. These are equal. Phil > - 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
Re: [dbcp] 1.3/1.4 RC1 available for review
Jörg Schaible wrote: > Phil Steitz wrote: > >> Phil Steitz wrote: >>> Jörg Schaible wrote: Jörg Schaible wrote: > Jörg Schaible wrote: > >> Hi Phil, >> >> Phil Steitz wrote: >> >> [snip] >> > 1.4 (JDBC 4) version: > http://people.apache.org/~psteitz/dbcp-1.4-rc1 > http://people.apache.org/~psteitz/dbcp-1.4-rc1/site > http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven > > http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with IBM 1.6.0.6: == %< > --- Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource > --- Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 sec <<< FAILURE! > testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) Time elapsed: 0.066 sec <<< FAILURE! junit.framework.AssertionFailedError: Expecting SQLException - XAResources orphaned at junit.framework.Assert.fail(Assert.java:47) at > org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) >>> I could use some help debugging this one. I do not have the JDK to >>> test with and the failure makes no sense to me. Does it happen >>> every time? >> It seems it was caused by a difference in the WeakReference >> implementation. The DelegactingConnection returned the same hashCode >> than the inner connection. However, both instances were kept in the >> registry in xaReference (a WeakMap). >>> >>> Need to figure out why that is happening. This could be a test bug. >>> The connection should only be added once to the registry. >>> >>> After using a distinguishable hashCode, the >> test succeeds also with IBM JDK. >> >> Additionally I dropped the JDK 1.4 deps from the POM. >>> >>> That is OK for the trunk POM. Thanks. >> I'll look into DBCP 1.3 ASAP - it got too late now ;-) > Guess it was really too late yesterday. While > TestBasicManagedDataSource works now, my change borked the > TestManagedDataSourceInTx tests (interestingly 33 with Sun JDK, but > only 28 with IBM). Basically my change broke the contract with > hashCode that should be the same for "equal" objects. > > Question is now, what to do. If we revert the change, the IBM JDK is > broken and it fails to release the transactions. Otherwise we have to > change additionally the equals method, so that a DelegatingConnection > is not equal to the wrapped Connection. However, this may case even > more hick-ups. I've reverted the hashCode change for now that brings back the IBM JDK problem. :-/ >>> >>> Thanks, Jorg. I think changing equals is not a good idea. Thanks >>> again for your help. >>> >> >> This is a test bug. The test is manually registering the connection >> after the LocalXAConnectionFactory has already done it. Fixing >> now. This should eliminate the problem. > > The funny thing is that on Sun JDK registering the ManagedConnection > itself will update the entry in the WeakHashMap of the delegated > connection. On IBM JDK a new entry is created in the map. Later on is the > ManagedConnection removed, but the lookup will now return the delegated > connection (may be because of equality of the connection and its hash code > when it is used as key. IBM JDK 1.6 tested - runs fine now. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Phil Steitz wrote: > Phil Steitz wrote: >> Jörg Schaible wrote: >>> Jörg Schaible wrote: >>> Jörg Schaible wrote: > Hi Phil, > > Phil Steitz wrote: > > [snip] > 1.4 (JDBC 4) version: http://people.apache.org/~psteitz/dbcp-1.4-rc1 http://people.apache.org/~psteitz/dbcp-1.4-rc1/site http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ >>> Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 >>> and Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it >>> fails with IBM 1.6.0.6: >>> >>> == %< >>> >>> --- >>> Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource >>> >>> --- >>> Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: >>> 3.398 sec <<< FAILURE! >>> >>> testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) >>> Time elapsed: 0.066 sec <<< FAILURE! >>> junit.framework.AssertionFailedError: Expecting SQLException - >>> XAResources orphaned >>> at junit.framework.Assert.fail(Assert.java:47) >>> at >>> >>> org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) >> I could use some help debugging this one. I do not have the JDK to >> test with and the failure makes no sense to me. Does it happen >> every time? > It seems it was caused by a difference in the WeakReference > implementation. The DelegactingConnection returned the same hashCode > than the inner connection. However, both instances were kept in the > registry in xaReference (a WeakMap). >> >> Need to figure out why that is happening. This could be a test bug. >> The connection should only be added once to the registry. >> >> After using a distinguishable hashCode, the > test succeeds also with IBM JDK. > > Additionally I dropped the JDK 1.4 deps from the POM. >> >> That is OK for the trunk POM. Thanks. > I'll look into DBCP 1.3 ASAP - it got too late now ;-) Guess it was really too late yesterday. While TestBasicManagedDataSource works now, my change borked the TestManagedDataSourceInTx tests (interestingly 33 with Sun JDK, but only 28 with IBM). Basically my change broke the contract with hashCode that should be the same for "equal" objects. Question is now, what to do. If we revert the change, the IBM JDK is broken and it fails to release the transactions. Otherwise we have to change additionally the equals method, so that a DelegatingConnection is not equal to the wrapped Connection. However, this may case even more hick-ups. >>> I've reverted the hashCode change for now that brings back the IBM JDK >>> problem. :-/ >> >> Thanks, Jorg. I think changing equals is not a good idea. Thanks >> again for your help. >> > > This is a test bug. The test is manually registering the connection > after the LocalXAConnectionFactory has already done it. Fixing > now. This should eliminate the problem. The funny thing is that on Sun JDK registering the ManagedConnection itself will update the entry in the WeakHashMap of the delegated connection. On IBM JDK a new entry is created in the map. Later on is the ManagedConnection removed, but the lookup will now return the delegated connection (may be because of equality of the connection and its hash code when it is used as key. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Phil Steitz wrote: > Jörg Schaible wrote: >> Jörg Schaible wrote: >> >>> Jörg Schaible wrote: >>> Hi Phil, Phil Steitz wrote: [snip] >>> 1.4 (JDBC 4) version: >>> http://people.apache.org/~psteitz/dbcp-1.4-rc1 >>> http://people.apache.org/~psteitz/dbcp-1.4-rc1/site >>> http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven >>> http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ >> Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and >> Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with >> IBM 1.6.0.6: >> >> == %< >> >> --- >> Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource >> >> --- >> Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 >> sec <<< FAILURE! >> >> testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) >> Time elapsed: 0.066 sec <<< FAILURE! >> junit.framework.AssertionFailedError: Expecting SQLException - >> XAResources orphaned >> at junit.framework.Assert.fail(Assert.java:47) >> at >> >> org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) > I could use some help debugging this one. I do not have the JDK to > test with and the failure makes no sense to me. Does it happen > every time? It seems it was caused by a difference in the WeakReference implementation. The DelegactingConnection returned the same hashCode than the inner connection. However, both instances were kept in the registry in xaReference (a WeakMap). > > Need to figure out why that is happening. This could be a test bug. > The connection should only be added once to the registry. > > After using a distinguishable hashCode, the test succeeds also with IBM JDK. Additionally I dropped the JDK 1.4 deps from the POM. > > That is OK for the trunk POM. Thanks. I'll look into DBCP 1.3 ASAP - it got too late now ;-) >>> Guess it was really too late yesterday. While TestBasicManagedDataSource >>> works now, my change borked the TestManagedDataSourceInTx tests >>> (interestingly 33 with Sun JDK, but only 28 with IBM). Basically my change >>> broke the contract with hashCode that should be the same for "equal" >>> objects. >>> >>> Question is now, what to do. If we revert the change, the IBM JDK is >>> broken and it fails to release the transactions. Otherwise we have to >>> change additionally the equals method, so that a DelegatingConnection is >>> not equal to the wrapped Connection. However, this may case even more >>> hick-ups. >> I've reverted the hashCode change for now that brings back the IBM JDK >> problem. :-/ > > Thanks, Jorg. I think changing equals is not a good idea. Thanks > again for your help. > This is a test bug. The test is manually registering the connection after the LocalXAConnectionFactory has already done it. Fixing now. This should eliminate the problem. Phil > Phil >> - 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
[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 8 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. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -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: 8 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-16122009.jar:/srv/gump/pu blic/workspace/commons-collections-3.x/target/commons-collections-3.3-SNAPSHOT.jar:/srv/gump/public/workspace/commons-jelly/target/commons-jelly-16122009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/ant/target/commons-jelly-tags-ant-16122009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/beanshell/target/commons-jelly-tags-beanshell-16122009.jar:/srv/gump/public/workspace/commons-jelly/jelly-tags/junit/target/commons-jelly-tags-junit-16122009.jar:/srv/gump/public/workspace/commons-jexl-1.x/target/commons-jexl-1.1.1-SNAPSHOT.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-16122009.jar:/srv/gump/public/workspace/apache-commons/logging/target/commons-logging-api-16122009.jar:/srv/gump/public/workspace/dom4j/build/dom4j.jar:/srv/gump/public/workspace/jaxen/target/jaxen-16122009.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-jell y-tags-fmt-16122009.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.runTe
[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 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-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: 7 mins 26 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:/srv/gump/public/workspace/apache-commons/jexl/target/commons-jexl-2.0-SNAPSHOT.jar - testInitCopy(org.apache.commons.configuration.TestXMLConfiguration) testSaveWithDelimiterParsingDisabled(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: 1456, Failures: 0, Errors: 58, Skipped: 0 [INFO] ---
Re: svn commit: r891144 - /commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
sebb wrote at Mittwoch, 16. Dezember 2009 13:06:
> On 16/12/2009, joe...@apache.org wrote:
>> Author: joehni
>> Date: Wed Dec 16 07:38:09 2009
>> New Revision: 891144
>>
>> URL: http://svn.apache.org/viewvc?rev=891144&view=rev
>> Log:
>> Restore Ant markers.
[snip]
>>
>> +// --- JDBC 3.0
>> -
>> +// Will be commented by the build process on a JDBC 2.0 system
>> +
>> +/* JDBC_3_ANT_KEY_BEGIN */
>
> DBCP no longer needs JDBC_3 markers; these have already been removed.
>
>> +
>> public int getHoldability() throws SQLException
>> { checkOpen(); try { return _conn.getHoldability(); } catch
>> { (SQLException e) { handleException(e); return 0; } }
>>
>> @@ -531,7 +538,7 @@
>> return null;
>> }
>> }
>> -
>> +/* JDBC_3_ANT_KEY_END */
>
> DBCP no longer needs JDBC_3 markers; these have already been removed.
>
>> /* JDBC_4_ANT_KEY_BEGIN */
>>
>> public boolean isWrapperFor(Class iface) throws SQLException {
Sigh. Reverted one change too much. If something's already gone wrong, it
tends to get worse ;-)
- Jörg
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r891144 - /commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
On 16/12/2009, joe...@apache.org wrote:
> Author: joehni
> Date: Wed Dec 16 07:38:09 2009
> New Revision: 891144
>
> URL: http://svn.apache.org/viewvc?rev=891144&view=rev
> Log:
> Restore Ant markers.
>
> Modified:
>
> commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
>
> Modified:
> commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
> URL:
> http://svn.apache.org/viewvc/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java?rev=891144&r1=891143&r2=891144&view=diff
>
> ==
> ---
> commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
> (original)
> +++
> commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/DelegatingConnection.java
> Wed Dec 16 07:38:09 2009
> @@ -17,27 +17,29 @@
>
> package org.apache.commons.dbcp;
>
> -import java.sql.Array;
> -import java.sql.Blob;
> import java.sql.CallableStatement;
> -import java.sql.ClientInfoStatus;
> -import java.sql.Clob;
> import java.sql.Connection;
> import java.sql.DatabaseMetaData;
> -import java.sql.NClob;
> import java.sql.PreparedStatement;
> -import java.sql.ResultSet;
> -import java.sql.SQLClientInfoException;
> import java.sql.SQLException;
> import java.sql.SQLWarning;
> -import java.sql.SQLXML;
> import java.sql.Statement;
> -import java.sql.Struct;
> -import java.util.Collections;
> import java.util.Iterator;
> import java.util.List;
> import java.util.Map;
> +import java.sql.ResultSet;
> +/* JDBC_4_ANT_KEY_BEGIN */
> +import java.sql.Array;
> +import java.sql.Blob;
> +import java.sql.ClientInfoStatus;
> +import java.sql.Clob;
> +import java.sql.NClob;
> +import java.sql.SQLClientInfoException;
> +import java.sql.SQLXML;
> +import java.sql.Struct;
> +import java.util.Collections;
> import java.util.Properties;
> +/* JDBC_4_ANT_KEY_END */
>
> /**
> * A base delegating implementation of {...@link Connection}.
> @@ -436,6 +438,11 @@
> }
> }
>
> +// --- JDBC 3.0
> -
> +// Will be commented by the build process on a JDBC 2.0 system
> +
> +/* JDBC_3_ANT_KEY_BEGIN */
DBCP no longer needs JDBC_3 markers; these have already been removed.
> +
> public int getHoldability() throws SQLException
> { checkOpen(); try { return _conn.getHoldability(); } catch
> (SQLException e) { handleException(e); return 0; } }
>
> @@ -531,7 +538,7 @@
> return null;
> }
> }
> -
> +/* JDBC_3_ANT_KEY_END */
DBCP no longer needs JDBC_3 markers; these have already been removed.
> /* JDBC_4_ANT_KEY_BEGIN */
>
> public boolean isWrapperFor(Class iface) throws SQLException {
>
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] 1.3/1.4 RC1 available for review
Jörg Schaible wrote: > Jörg Schaible wrote: > >> Jörg Schaible wrote: >> >>> Hi Phil, >>> >>> Phil Steitz wrote: >>> >>> [snip] >>> >> 1.4 (JDBC 4) version: >> http://people.apache.org/~psteitz/dbcp-1.4-rc1 >> http://people.apache.org/~psteitz/dbcp-1.4-rc1/site >> http://people.apache.org/~psteitz/dbcp-1.4-rc1/maven >> http://svn.apache.org/repos/asf/commons/proper/dbcp/tags/DBCP_1_4_RC1/ > Builds from source and runs tests with IcedTea6 1.6.2, Sun JDK 1.6 and > Sun JDK 1.7.0.0.alpha69 (add to README.txt ?!?). However it fails with > IBM 1.6.0.6: > > == %< > > --- > Test set: org.apache.commons.dbcp.managed.TestBasicManagedDataSource > > --- > Tests run: 46, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.398 > sec <<< FAILURE! > > testReallyClose(org.apache.commons.dbcp.managed.TestBasicManagedDataSource) > Time elapsed: 0.066 sec <<< FAILURE! > junit.framework.AssertionFailedError: Expecting SQLException - > XAResources orphaned > at junit.framework.Assert.fail(Assert.java:47) > at > > org.apache.commons.dbcp.managed.TestBasicManagedDataSource.testReallyClose(TestBasicManagedDataSource.java:72) I could use some help debugging this one. I do not have the JDK to test with and the failure makes no sense to me. Does it happen every time? >>> It seems it was caused by a difference in the WeakReference >>> implementation. The DelegactingConnection returned the same hashCode than >>> the inner connection. However, both instances were kept in the registry >>> in xaReference (a WeakMap). Need to figure out why that is happening. This could be a test bug. The connection should only be added once to the registry. After using a distinguishable hashCode, the >>> test succeeds also with IBM JDK. >>> >>> Additionally I dropped the JDK 1.4 deps from the POM. That is OK for the trunk POM. Thanks. >>> >>> I'll look into DBCP 1.3 ASAP - it got too late now ;-) >> Guess it was really too late yesterday. While TestBasicManagedDataSource >> works now, my change borked the TestManagedDataSourceInTx tests >> (interestingly 33 with Sun JDK, but only 28 with IBM). Basically my change >> broke the contract with hashCode that should be the same for "equal" >> objects. >> >> Question is now, what to do. If we revert the change, the IBM JDK is >> broken and it fails to release the transactions. Otherwise we have to >> change additionally the equals method, so that a DelegatingConnection is >> not equal to the wrapped Connection. However, this may case even more >> hick-ups. > > I've reverted the hashCode change for now that brings back the IBM JDK > problem. :-/ Thanks, Jorg. I think changing equals is not a good idea. Thanks again for your help. Phil > > - 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
Re: [lang] JIRA change
Better 3.0 specific link: https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310481&versionId=12311714&showOpenIssuesOnly=true On Wed, Dec 16, 2009 at 12:42 AM, Henri Yandell wrote: > I added some components to the JIRA project: > > https://issues.apache.org/jira/browse/LANG > > It shows that the builder package is the major item of work remaining > with ~20% of open issues for 3.0. > > Hen > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] JIRA change
I added some components to the JIRA project: https://issues.apache.org/jira/browse/LANG It shows that the builder package is the major item of work remaining with ~20% of open issues for 3.0. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
