Re: [D] log4j2 plugin discovery in Websphere Application Ser ver environment [logging-log4j2]

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]