[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051836#comment-17051836
]
Ralph Goers commented on LOG4J2-2795:
-------------------------------------
Without plugins you can only have the DefaultConfiguration. Plugins are lazily
loaded in a sense. The collectPlugins method is called from 1 of 4 places: 1)
AbstractConfiguration.initialize() when a Configuration is being created. 2)
Interpolator's constructor when Lookups need to be found 3) PatternParser's
constructor when PatternConverters need to be located, and 4) WatcherFactory's
constructor when Watchers are located. These are basically the 4 classes of
plugins currently supported in Log4j 2. Only the first one of these to be
called actually loads the plugins - it wouldn't make any sense to do it any
other way as they are all defined in the same file (Log4jPlugins.dat in 2.x and
Log4jPlugins.java in 3.x). As I said, it 3.x the major cost is in
ServiceLoader locating Log4jPlugins.java, not in loading the actual plugins.
> 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
> Attachments: log4j2.png
>
>
> 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)
