commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DBCP-358) Equals implementations in DelegatingXxx classes are not symmetric
Date Tue, 04 Feb 2014 12:28:11 GMT

    [ https://issues.apache.org/jira/browse/DBCP-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13890611#comment-13890611
] 

Mark Thomas commented on DBCP-358:
----------------------------------

I have a great deal of sympathy with the point that Balazs makes above. I intend to explore
removing the custom equals and hashcode methods entirely. I know that this is going to break
a bunch of tests. What I need to look at is whether the tests are just testing for the current
behaviour or whether - like TransactionRegistry - the implementation actually depends on the
current behaviour. Assuming it is the former, I'll change the tests. If it is the latter,
I'll have to see what options I'm left with.

Regarding the TransactionRegistry, there is going to have to be a hack of some form somewhere.
My preferred approach at the moment is to make getInnermostDelegateInternal() public but make
it clear in the Javadoc that it is not part of the API. What I like about this is that it
becomes very clear that the code that depends on the innermost delegate rather than having
a dependency on an equals implementation several hops away. This should also provide a route
to change any other code that depends on the current equals and hashcode behaviour.

> 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.5#6160)

Mime
View raw message