[
https://issues.apache.org/jira/browse/LOG4J2-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14381144#comment-14381144
]
Ralph Goers commented on LOG4J2-891:
------------------------------------
Unless the equals and hashcode methods provide a valid implementation to all
classes that inherit it then I don't think it is a good idea for the methods to
be there.
> AbstractLifecycle should not implement equals() and hashCode()
> --------------------------------------------------------------
>
> Key: LOG4J2-891
> URL: https://issues.apache.org/jira/browse/LOG4J2-891
> Project: Log4j 2
> Issue Type: Bug
> Components: API
> Affects Versions: 2.1
> Reporter: Mariano Gonzalez
> Fix For: 2.2
>
>
> Starting with version 2.1, the AbstractLifeCycle class (which I think was
> also introduced in that version) have an implementation of equals() and
> hashCode() which is being inherited by other core classes such as
> LoggerContext. That implementation considers two objects as equals if they
> have the same LifeCycle.State, and calculates the hashCode based on that same
> attribute.
> This has unwanted side effects:
> * For a class like LoggerContext, that implementation of equals() doesn't
> apply at all. For example, I'm using log4j2 as the logging technology for an
> application container. Each deployed application get its own LoggerContext.
> Those LoggerContext are not equal just because they have the same status.
> * AbstractLifeCycle instances are no longer suitable for use in a HashSet or
> HashMap. Because every instance with the same state will return the same
> hashCode, changes are that many of them will end up in the same bucket. Also,
> because of the same reasons which make the equals() implementation wrong,
> invokations to HashSet#contains(AbstractLifeCycle) might start showing
> unexpected behavior.
> This was fine in 2.0.2 and I have verified these issues with the
> LoggerContext class. I'm pretty sure that the same thing happens to all its
> subclasses. I don't think that the state is a good attribute to determine
> equality or idempotency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
