[
https://issues.apache.org/jira/browse/LOG4J2-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16378605#comment-16378605
]
Anton Korenkov edited comment on LOG4J2-2272 at 2/27/18 1:51 PM:
-----------------------------------------------------------------
I've debugged both test code and one of our components. Here is the debug trace
from test case:
# logger.log(Level.ERROR, "Test message");
# log:1629, AbstractLogger (org.apache.logging.log4j.spi)
# logIfEnabled:1960, AbstractLogger (org.apache.logging.log4j.spi)
# logMessage:1988, AbstractLogger (org.apache.logging.log4j.spi)
# logMessageSafely:2091, AbstractLogger (org.apache.logging.log4j.spi)
# logMessage:132, AsyncLogger (org.apache.logging.log4j.core.async)
# logWithThreadLocalTranslator:160, AsyncLogger
(org.apache.logging.log4j.core.async)
# initTranslator:191, AsyncLogger (org.apache.logging.log4j.core.async)
# calcLocationIfRequested:222, AsyncLogger
(org.apache.logging.log4j.core.async) // here we are checking includeLocation
flag which is true
# calcLocation:633, Log4jLogEvent (org.apache.logging.log4j.core.impl)
//fcqnOfLogger is not null and here we are going to expensive new
Throwable().getStackTrace()
For me is not quite obvious some code in
{{org.apache.logging.log4j.core.config.LoggerConfig}}. The includeLocation
defaults to true and we have two constructors that don't check is async context
selector was set or not. Maybe it's due to historical reasons. What do you
think, maybe it should be checked in public constructors without
includeLocation parameter?
was (Author: korenkov):
I've debugged both test code and one of our components. Here is the debug trace
from test case:
{{
logger.log(Level.ERROR, "Test message");
log:1629, AbstractLogger (org.apache.logging.log4j.spi)
logIfEnabled:1960, AbstractLogger (org.apache.logging.log4j.spi)
logMessage:1988, AbstractLogger (org.apache.logging.log4j.spi)
logMessageSafely:2091, AbstractLogger (org.apache.logging.log4j.spi)
logMessage:132, AsyncLogger (org.apache.logging.log4j.core.async)
logWithThreadLocalTranslator:160, AsyncLogger
(org.apache.logging.log4j.core.async)
initTranslator:191, AsyncLogger (org.apache.logging.log4j.core.async)
calcLocationIfRequested:222, AsyncLogger (org.apache.logging.log4j.core.async)
// here we are checking includeLocation flag which is true
calcLocation:633, Log4jLogEvent (org.apache.logging.log4j.core.impl)
//fcqnOfLogger is not null and here we are going to expensive new
Throwable().getStackTrace()
}}
For me is not quite obvious some code in
{{org.apache.logging.log4j.core.config.LoggerConfig}}. The includeLocation
defaults to true and we have two constructors that don't check is async context
selector was set or not. Maybe it's due to historical reasons. What do you
think, maybe it should be checked in public constructors without
includeLocation parameter?
> includeLocation property for async loggers
> ------------------------------------------
>
> Key: LOG4J2-2272
> URL: https://issues.apache.org/jira/browse/LOG4J2-2272
> Project: Log4j 2
> Issue Type: Question
> Components: Core
> Affects Versions: 2.10.0
> Reporter: Anton Korenkov
> Priority: Minor
>
> According to [link|https://logging.apache.org/log4j/2.0/manual/async.html]:
> {quote}By default,
> [location|https://logging.apache.org/log4j/2.0/manual/async.html#Location] is
> not passed to the I/O thread by asynchronous loggers. If one of your layouts
> or custom filters needs location information, you need to set
> "includeLocation=true" in the configuration of all relevant loggers,
> including the root logger.
> {quote}
> However, if I create logger with default configuration and
> '-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector'
> vm option 'includeLocation' defaults to 'true'. Is it expected behavior or
> glitch?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
