[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17049958#comment-17049958
]
Ralph Goers commented on LOG4J2-2795:
-------------------------------------
I guess I wasn't clear. When you call getLogger the FQCN of the Logging
implementation is passed in so that the calling class can be identified. This
is necessary because the ClassLoaderContextSelector uses that to determine
which ClassLoader was used, and hence, which LoggerContext should be used. For
example, if you are running in tomcat with the jars in Tomcat's lib directory
and you use Log4j 2 to log Tomcat then when Tomcat logs it will use the
LoggerContext associated with Tomcat's ClassLoader. Web apps will use the
LoggerContext associated with the WebApp ClassLoader. This should allow you to
have multiple logging configurations.
So the point is, the ClassLoaderContextSelector has to walk the stack to locate
the calling Class. This has some overhead, but it is only performed once for
each Logger that is obtained.
> Make LogManager/LoggerContext creation time reasonable
> ------------------------------------------------------
>
> Key: LOG4J2-2795
> URL: https://issues.apache.org/jira/browse/LOG4J2-2795
> Project: Log4j 2
> Issue Type: Task
> Components: Core
> Affects Versions: 2.13.0
> Reporter: Romain Manni-Bucau
> Priority: Major
>
> Currently (2.13), LogManager.getLogger("xxx") takes ~600ms on a cold JVM by
> itself.
> For a logging framework it is likely way too much (by comparison a CDI test
> with classpath scanning takes ~50ms).
>
> This ticket is about trying to be faster (maybe by removing java
> serialization usage and reducing registry usage + reflection of plugins by
> generating java code?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
