[
https://issues.apache.org/jira/browse/LOG4J2-891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196836#comment-14196836
]
Mariano Gonzalez commented on LOG4J2-891:
-----------------------------------------
For LoggerContext I think it should be the identity itself. Back to the
application container example, I can deploy an application and generate a
LoggerContext for it with name "myApp". Then I can redeploy that application
(even maybe with a different log4j config), and that would generate a new
LoggerContext which has the same name but is fundamentally different.
I think I can probably imagine similar scenarios for all the subclasses of
AbstractLifeCycle that I've seen. Even if using the state as a key works for
the other examples, the fact that the hashCode functions has low dispersion is
still an issue.
> 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]
