The PluginRegistry handles [ClassNotFoundException |https://i/apache/logging-log4j2/blob/e741549928b2acbcb2d11ad285aa84ee88728e49/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/util/PluginRegistry.java#L185|https://github.com/apache/logging-log4j2/blob/e741549928b2acbcb2d11ad285aa84ee88728e49/log4j-core/src/main/java/org/apache/logging/log4j/core/config/plugins/util/PluginRegistry.java#L185]] but does not handle unchecked exceptions like NoClassDefFoundError. As a result applications may not start when loading of a plugin fails with an unchecked exception.
Here is the scenario we ran into:
We use logstash-gelf in a standardized Tomcat docker images to send Java Util Logging (as used by Tomcat) to Graylog. To do this we add the logstash-gelf jar to the $CATALINA_HOME/lib directory, effectively placing it on Tomcat's common loader classpath. In essence there is no log4j involved, but the logstash-gelf jar contains integrations for various logging frameworks, including a log4j2 appender.
When a webapplication that is deployed on this Tomcat instance uses log4j2 as logging framework the logstash-gelf appender is found during plugin scanning and the PluginRegistry tries to load it (even if the appender is not used in the log4j configuration). The logstash-gelf plugin is not loaded via the webapplication classloader, but through the parent common loader. It can find the plugin class but not the dependent log4j2 classes as they are only on the classpath of the webapplication classloader: