logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-891) AbstractLifecycle should not implement equals() and hashCode()
Date Thu, 26 Mar 2015 00:04:53 GMT

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

Sean commented on LOG4J2-891:

I'm quite new to log4j2 so I don't know what the right fix is. It would seem that the previous
code checked AbstractLifeCycle which compared State's, and then AbstractFilter compared onMatch
and onMismatch, If AbstractLifeCycle is not going to have equals() but State is still important,
I suppose AbstractFilter could simply remove the call to super.equals() and check State itself.
Both classes already checked for identity and class type.  So, that given I'm not aware of
all of the resulting consequences, I'd propose AbstractFilter be changed to:

    public boolean equals(final Object obj) {
        if (this == obj) {
            return true;
        if (getClass() != obj.getClass()) {
            return false;
        final AbstractFilter other = (AbstractFilter) obj;
        if (getState() != other.getState()) {
            return false;
        if (onMatch != other.onMatch) {
            return false;
        if (onMismatch != other.onMismatch) {
            return false;
        return true;

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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message