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). After using a distinguishable hashCode, the >> test succeeds also with IBM JDK. >> >> Additionally I dropped the JDK 1.4 deps from the POM. >> >> 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. :-/ - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
