[
https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027967#comment-13027967
]
Joerg Schaible commented on DBCP-358:
-------------------------------------
Thinking about it ... if I create a *temporary* connection instance and use it
as key in a WeakHashMap, it does not make too much sense either. OTOH, if I use
an unwrapped connection as key that is also part of the WeakHashMap's value
(the xaResource), the WeakHashMap is also useless. So, what do we try to solve
with the WeakHashMap for the XAResources here?
> 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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
