You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Ian Barfield (JIRA)" <ji...@apache.org> on 2014/08/25 19:22:59 UTC
[jira] [Comment Edited] (LOG4J2-798) jar scanning for plugins too
expensive and called too many times
[ https://issues.apache.org/jira/browse/LOG4J2-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109334#comment-14109334 ]
Ian Barfield edited comment on LOG4J2-798 at 8/25/14 5:22 PM:
--------------------------------------------------------------
Some additional digging reveals the following:
the first message is from {{AbstractConfiguration.start()}} at line 133 {{pluginManager.collectPlugins();}}. It loads the "Core" plugins and works correctly (quickly). The next call with {{preload: true}} is from the very next two lines after at 134 and 135 where it looks for any plugins with the category "Level". Since there are none defined via the plugin system by default, it adds the default log4j package to the list of 'packages' and thereby dooms itself and all subsequent calls to require jar scanning.
That case could be fixed, but I would still classify the repeated full jar scans as a bug in its own right. There should be no re-scans unless there are additional packages to look for.
was (Author: ianbarfield):
Some additional digging reveals the following:
the first message is from {{AbstractConfiguration.start()}} at line 133 {{pluginManager.collectPlugins();}}. It loads the "Core" plugins and works correctly (quickly). The next call with {{preload: true}} is from the very next two lines after at 134 and 135 where it looks for any plugins with the category "Level". Since there are none defined via the plugin system by default, it adds the default log4j package to the list of 'packages' and thereby dooms all subsequent calls to require jar scanning.
That case could be fixed, but I would still classify the repeated full jar scans as a bug in its own right. There should be no re-scans unless there are additional packages to look for.
> jar scanning for plugins too expensive and called too many times
> ----------------------------------------------------------------
>
> Key: LOG4J2-798
> URL: https://issues.apache.org/jira/browse/LOG4J2-798
> Project: Log4j 2
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.1, 2.0.2
> Environment: modern hardware, fat jar
> Reporter: Ian Barfield
>
> related to: [https://issues.apache.org/jira/browse/LOG4J2-741]
> It takes about 3 seconds to perform {{PluginManager.collectPlugins()}} and it appears to run 4 times before log4j2 is done initializing. That is pretty not okay. Please consider making the plugin discovery method configurable and/or curtailing the redundant calls.
> My application jar uses the maven shade plugin. I do not specify a 'packages' attribute. I do use a custom plugin (a configuration factory), but I excluded the resultant plugin dat file created for it and specify its usage at runtime via the appropriate system property.
> My suggestion for the easiest fix is to use the pre-computed plugin list and optionally (maybe even enabled by default) also scan the class path for custom plugins.
> Some nice extras would be:
> - removing the redundant {{collectPlugins()}} calls
> - using a plugin dat file format that is both human friendly and amenable to append operations so that users of the maven shade plugin and users who struggle with annotation processors can easily include custom plugins. See [https://github.com/addthis/codec] for an example of such a plugin system/ file format that is based on hocon.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org