logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-1585) Logger.getParent gives warning about MessageFactory mismatch
Date Fri, 16 Sep 2016 11:04:21 GMT

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

Remko Popma commented on LOG4J2-1585:

I looked at this in more detail. I can see [~shangdi]'s point that simply calling {{logger.getParent()}}
should not result in a warning. The suggested fix is one idea that may help, but note that
this fix will only make the warnings go away if the parent logger uses the default message

This is because of the way {{getLogger(String)}} and {{hasLogger(String)}} are currently implemented:
these methods look for a logger with that name _that uses the default message factory_. It
does not scan through the list to see if it can find a logger with the specified name regardless
of the message factory... 

About the warnings, is this something that happens once during initialization, or many times
during the life of the application?

> Logger.getParent gives warning about MessageFactory mismatch
> ------------------------------------------------------------
>                 Key: LOG4J2-1585
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1585
>             Project: Log4j 2
>          Issue Type: Bug
>    Affects Versions: 2.6.2
>            Reporter: Di Shang
> Hi
> I just noticed a lot of warning spam in my log like this:
> 2016-09-15 14:59:16,322 main WARN The Logger  was created with the message factory org.apache.logging.log4j.message.ReusableMessageFactory@51e2adc7
and is now requested with the message factory org.apache.logging.log4j.message.ReusableMessageFactory@1a8a8f7c,
which may create log events with unexpected formatting.
> The root cause of this is in Logger.getParent() :
> {code:java}
>         final MessageFactory messageFactory = getMessageFactory();
>         if (context.hasLogger(lcName, messageFactory)) {          // <=====
>             return context.getLogger(lcName, messageFactory);   // <=====
>         }
>         return new Logger(context, lcName, messageFactory);
> {code}
> It is trying to fetch the parent logger using the child's messageFactory, which will
cause the warning from context.getLogger. To me this looks like a bug since the parent and
child can have different messageFactory instance. (or are they supposed to be the same?)
> Easy way to reproduce this:
> {code:java}
>         LogManager.getRootLogger();
>         Logger logger = LogManager.getLogger("foo");
>         ((org.apache.logging.log4j.core.Logger) logger).getParent();
> {code}
> I was thinking about a fix like this:
> {code:java}
>         if (context.hasLogger(lcName)) {
>             return context.getLogger(lcName);
>         }
>         return new Logger(context, lcName, getMessageFactory());
> {code}
> But it doesn't look quite right because the LoggerRegistry seems to identify unique logger
by (MF_class_name, logger_name) meaning there can be multiple loggers of the same name but
different MF class. 
> So the real question is if the parent-child relationship is determined by the name only
but there are multiple loggers of the same name, how can we uniquely determine the parent
> Reviewing the log4j 2 architecture documentation, I realized that it only mentions about
parent-child relationship between LoggerConfig, not Loggers. 
> Does this mean that the parent-child hierarchy is only determined by the underlying LoggerConfig
and for a particular LoggerConfig there can be multiple loggers of the same name but different
MF. So Logger.getParent() doesn't make much sense any more and should not be used. Is my understanding
here correct?

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