GitHub user breygin edited a discussion: log4j2 plugin discovery in Websphere
Application Server environment
When log4j2 framework is initialized at parent classloader level, the log4j2
plugin extension classes packaged at child classloader level can not be
discovered. We have an environment with SiteMinder deployed at high level
classloader. SiteMinder uses log4j2 framework, it instantiates its
configuration and logging context.
Our application(s) deployed on the same Websphere server has its own log4j2.xml
configurations and configures its own logging context:
context = Configurator.initialize(new Integer(cl.hashCode()).toString(),cl,
configUri);
context.start();
context.updateLoggers();
cl is a classloader where the context is being created. What we observe is that
our custom log4j2 plugins packaged in a jar visible to that classloader are not
being discovered. It appears that entire plugin discovery happens once upon
initialization of log4j2 framework by SiteMinder classloader, which has no
visibility below its level because of PARENT_FIRST policy.
Just wanted to mention one more thing here, that adding JVM argument
-Dlog4j.plugin.packages=my.package.containing.log4j2.plugins
does not seem to make any difference. This system property
log4j.plugin.packages is mentioned in official log4j2 manual
https://logging.apache.org/log4j/2.x/manual/plugins.html#plugin-discovery
as one of the possible ways of plugin discovery:
3. [Deprecated] A comma-separated list of packages specified by the
log4j.plugin.packages system property
any tips, help and advice is greatly appreciated! More specifically, if there
is any way to "force" application classloader to look up extensions visible at
its packaging level?
GitHub link: https://github.com/apache/logging-log4j2/discussions/3963
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
