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. - Jörg > > - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
