[
https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832463#comment-13832463
]
Balazs Zsoldos commented on DBCP-358:
-------------------------------------
Would be nice to fix this issue in a way that equals and hashcode does not use
innermost.
A short example why a programmer feels the current behavior is a bug::
Connection conn1 = dataSource.getConnection();
conn1.close();
Connection conn2 = dataSource.getConnection();
if (conn2.equals(conn1) && conn1.isClosed() != conn2.isClosed()) {
// Oops they are equal but one of them is closed but the other is not
}
> Equals implementations in DelegatingXxx classes are not symmetric
> -----------------------------------------------------------------
>
> Key: DBCP-358
> URL: https://issues.apache.org/jira/browse/DBCP-358
> Project: Commons Dbcp
> Issue Type: Bug
> Affects Versions: 1.2, 1.2.2, 1.3, 1.4
> Reporter: Phil Steitz
> Fix For: 1.3.1, 1.4.1
>
>
> For reasons unclear to me, DelegatingConnection, DelegatingStatement,
> PoolGuardConnectionWrappers and other DBCP classes implement equals so that
> the wrapping class is considered equal to its innermost delegate JDBC object.
> This makes equals asymmetric when applied to a wrapper and its wrapped JDBC
> object - wrapper.equals(delegate) returns true, but delegate.equals(wrapper)
> will in general return false.
> I am pretty sure that DBCP itself does not rely on this bugged behavior, so I
> am inclined to fix it, making equals an equivalence relation on wrapper
> instances, with two considered equal iff their innermost delegates are equal.
> I can't imagine use cases where the bugged behavior is required. Can anyone
> else?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
