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
