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

Gary Gregory commented on LOG4J2-891:
-------------------------------------

For LoggerContext, the problem is that it should implement equals and hashCode. 
Which attributes should be considered? Just the {{name}}?

> 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]

Reply via email to