[
https://issues.apache.org/jira/browse/LOG4J2-1585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15495203#comment-15495203
]
Di Shang edited comment on LOG4J2-1585 at 9/16/16 2:57 AM:
-----------------------------------------------------------
I'm implementing a dynamic cascading filtering system where I can set filters
to individual logger name so that the filtering proceeds along the parent path,
e.g.
Add MyFilter(DEBUG) to Logger(foo)
Add MyFilter(INFO) to Logger(foo.bar)
When I do Logger(foo.bar).isEnabled(DEBUG), MyFilter(INFO) on Logger(foo.bar)
will return NEUTRAL (level doesn't match), then it gets the filter for the
parent of Logger(foo.bar), which is MyFilter(DEBUG) and will ACCEPT the level
I've been traversing the parent tree using Logger.getParent, which generates
all the warnings. So according to Log4j 2 architecture, am I supposed to be
using LoggerConfig for parent traversal instead?
As for the warning, I think it somewhat makes sense in the context of
context.getLogger(name, messageFactory) alone, the problem here is that we are
trying to overload this signature with 2 things: get OR create. In the get case
where the logger already exists, it is not clear what the intended usage is, is
the caller supposed to be passing in an equal MF instance for the lookup if
they have reference to the original MF instance used to create that logger? In
that case the warning is useful indicating the MF being altered. In the
getParent case, we already know that the MF instances are not necessarily equal
between the parent and child, it is guessing the parent by inferring the MF
class type from the child, here the warning is kinda meaningless.
Maybe adding a pure getter like context.getLogger(String name,
Class<MessageFactory> mfClass) without warning?
was (Author: shangdi):
I'm implementing a dynamic cascading filtering system where I can set filters
to individual logger name so that the filtering proceeds along the parent path,
e.g.
Add MyFilter(DEBUG) to Logger(foo)
Add MyFilter(INFO) to Logger(foo.bar)
When I do Logger(foo.bar).isEnabled(DEBUG), MyFilter(INFO) on Logger(foo.bar)
will return NEUTRAL (level doesn't match), then it gets the filter for the
parent of Logger(foo.bar), which is MyFilter(DEBUG) and will ACCEPT the level
I've been traversing the parent tree using Logger.getParent, which generates
all the warnings. So according to Log4j 2 architecture, am I supposed to be
using LoggerConfig for parent traversal instead?
As for the warning, I think it somewhat makes sense in the context of
context.getLogger(name, messageFactory) alone, the problem here is that we are
trying to overload this signature with 2 things: get OR create. In the get case
where the logger already exists, it is not clear what the intended usage is, is
the caller supposed to be passing in an equal MF instance for the lookup if
they have reference to the original MF instance used to create that logger? In
that case the warning is useful indicating the MF being altered. In the
getParent case, we already know that the MF instances are not necessarily equal
between the parent and child, it is guessing the parent by inferring the MF
class type from the child, here the warning is kinda meanless.
Maybe adding a pure getter like context.getLogger(String name,
Class<MessageFactory> mfClass) without warning?
> 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 logger?
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
