[
https://issues.apache.org/jira/browse/LOG4J2-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17641067#comment-17641067
]
Piotr Karwasz commented on LOG4J2-3487:
---------------------------------------
Thank you [~dmessink],
By the way, we are working on solutions that will render {{includeLocation}}
obsolete: cf LOG4J2-3628 and [PR
#1147|https://github.com/apache/logging-log4j2/pull/1147].
I would really appreciate your opinion on the direction the bytecode weaving
tool is taking. E.g. what would be the minimal set of features for the tool?
What logging APIs do we need to support?
> The LoggerConfig includeLocation defaults to true in 2.17.2
> -----------------------------------------------------------
>
> Key: LOG4J2-3487
> URL: https://issues.apache.org/jira/browse/LOG4J2-3487
> Project: Log4j 2
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 2.17.2
> Reporter: Dave Messink
> Priority: Major
> Attachments: log4j2-3487-1.patch, log4j2-3487-2.patch,
> log4j2-3487.patch
>
>
> We've found services running 2.17.2 to be slower than 2.17.1. A heat map
> indicates a StackWalker in log4j.
> I found that the code that Logger plugin calls into has changed. In 2.17.1
> the default config for includeLocation is based only on the configured value.
> In 2.17.2 it's based on the config value if present, but then defaults to
> !(context instanceof AsyncLoggerContext).
> Since none of our Logger elements declare includeLocation - the default
> behavior has changed causing all LogEvents to include their location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
