[
https://issues.apache.org/jira/browse/LOG4J2-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196895#comment-14196895
]
Paul Benedict commented on LOG4J2-891:
--------------------------------------
The question of implementing equals() is always about business equality. If you
can reasonably justify when two contexts are equal for the sake of business
logic, then okay; otherwise it's better to always say separate instances are
never equal (Object's default implementation). Personally, I don't see any
business equality for this class.
> 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
>
> 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]
