[
https://issues.apache.org/jira/browse/LOG4J2-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philipp Hedwig reopened LOG4J2-393:
-----------------------------------
I tried to test this with rev. 1521753, built new jar files and linked those in
the project. Despite the on code level great looking changes, I get the
following exception and stack trace during initialization:
{code}java.lang.AbstractMethodError:
javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V
at
org.apache.logging.log4j.core.config.XMLConfiguration.enableXInclude(XMLConfiguration.java:118)
at
org.apache.logging.log4j.core.config.XMLConfiguration.newDocumentBuilder(XMLConfiguration.java:97)
at
org.apache.logging.log4j.core.config.XMLConfiguration.<init>(XMLConfiguration.java:141)
at
org.apache.logging.log4j.core.config.XMLConfigurationFactory.getConfiguration(XMLConfigurationFactory.java:40)
at
org.apache.logging.log4j.core.config.ConfigurationFactory$Factory.getConfiguration(ConfigurationFactory.java:375)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:377)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:149)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:85)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:34)
at
org.apache.logging.log4j.LogManager.getLogger(LogManager.java:387){code}
I checked beta8 and the difference is: Calls to
{{factory.setNamespaceAware(true);}} and {{enableXInclude(factory);}} are new.
(_org.apache.logging.log4j.core.config.XMLConfiguration_, lines 96 and 97)
Somehow the provided {{DocumentBuilderFactory}}
(_org.apache.xerces.jaxp.DocumentBuilderFactoryImpl_) seems to not have
implemented the {{setFeature(String name, boolean value)}}-Method.
This might prevent many from upgrading to the newest version, since it might be
difficult to update the used xerces version.
> Low initialization performance when using Log4J with jar packages
> -----------------------------------------------------------------
>
> Key: LOG4J2-393
> URL: https://issues.apache.org/jira/browse/LOG4J2-393
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators, Core
> Affects Versions: 2.0-beta8
> Reporter: Philipp Hedwig
> Labels: performance
> Fix For: 2.0-beta9
>
>
> We discovered a huge performance difference when initializing Log4J with
> deployed jar packages compared to using it directly with normal class files.
> As it seems,
> _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInJar_
> is way slower than its counterpart
> _org.apache.logging.log4j.core.config.plugins.ResolverUtil#loadImplementationsInDirectory_
> and since this method gets called a few hundred times at initialization in
> this project, initialization of Log4J took more than 2 minutes with jar
> packages, compared to a few seconds with class files.
> The performance issue was already mentioned in
> [LOG4J2-184|https://issues.apache.org/jira/browse/LOG4J2-184], only without
> the jar problem.
> The solution to [LOG4J2-175|https://issues.apache.org/jira/browse/LOG4J2-175]
> might cause this, but we are unsure why the methods exactly get called this
> often.
> I just can tell that
> _org.apache.logging.log4j.core.config.plugins.PluginManager#collectPlugins()_
> gets called VERY often via
> _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_,
> which gets called by
> _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
> And _collectPlugins()_ is remapped to _collectPlugins(boolean preLoad, final
> String pkgs)_ with _collectPlugins(true, null);_. I'm unsure what this
> preLoad is for, since it gets overridden with false and apparently no kind of
> caching is used. In this method, _resolver.findInPackage(test, pkg);_ takes a
> whole lot of time searching within the jars, as described in the beginning.
> The only way to work around this was for us to extract the custom appender in
> a sperate ant build target, and with this in a seperate jar, to minimize the
> size of the jar, reducing the search time.
> Can you cache things and maybe reduce the calls to _collectPlugins()_? I
> don't see the probability of changing plugins during initialization as
> described in LOG4J2-175 or the comment in
> _org.apache.logging.log4j.core.config.BaseConfiguration#getPluginManager_.
> Introducing a variable for the plugin manager within the for loop in
> _org.apache.logging.log4j.core.config.XMLConfiguration#constructHierarchy_
> might be a good idea!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
