[
https://issues.apache.org/jira/browse/LOG4J2-2795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17053534#comment-17053534
]
Ralph Goers commented on LOG4J2-2795:
-------------------------------------
Here are my comments regarding the items on your list:
# The driving force behind Log4j 2 3.x is to fully conform with the Java
Platform Module System. This means that Log4j Core can only have a required
dependency on java.base. The work to accomplish this will be handled under
LOG4J2-2802, which would include the ScriptEngine, which is now part of
java.scripting. That said, according to my profiling the ScriptManager
constructor only uses 16 ms.
# This doesn't make sense to me. Plugins are packaged as 1 class per jar. All
the plugin definitions in that jar are loaded at once. All the plugin
definitions have to be loaded otherwise the plugin won't be found when the
configuration is processed. I have already optimized this as much as possible
by not loading the plugin classes until they are referenced.
# ConfigurationFactory does have a static extension. If you provide a system
property naming your ConfigurationFactory it will be used. The current system
allows users to create their own custom configuration factories as plugins,
which is much simpler for users to implement.
# The Interpolator has to load the initial list of Lookups because the
PluginManager isn't available yet and variable resolution has to work while
processing the configuration but before the PluginManager is created. Creating
Lookups should generally be inexpensive. Without this values specified in the
properties section of the Log4j configuration would not be allowed to reference
Lookups.
> 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: image-2020-03-06-08-58-21-169.png, 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)
