Loading of custom deny-all filter can cause a StackOverflowError when deploying to Tomcat with Log4j2 configured to use a single JVM-wide logger context

[ppkarwasz]

This PR replaces the custom "deny all" filter used by Log4J2LoggingSystem with the standard DenyAllFilter, which is available since Log4j Core 2.13.0.

The purpose of this change is:

• to simplify the code base,
• to work around a pesky interaction between the custom Spring Boot filter and Tomcat's classloader (cf. StackOverflowException in Logger.isEnabled with Spring Boot 3 + Tomcat apache/logging-log4j2#1430). If Log4j Core is configured to use a single logger context for the whole JVM, Spring Boot will add its custom filter implementation (contained in Spring Boot's classloader) to the global logging system. Since Tomcat's classloader performs logging calls, this will cause a StackOverflowException while attempting to resolve the filter class. Using a class from Log4j Core (which must be in the system classloader in this configuration) will work around the problem.

[wilkinsona]

Thanks very much, @ppkarwasz.

[ppkarwasz]

You're welcome, @wilkinsona.

There are still some small adjustments to the Log4j2LoggingSystem I would like to contribute in preparation for the upcoming Log4j Core 3.x release (e.g. a fix of apache/logging-log4j2#1799). Any chance we can make it in time for Spring Boot 3.3.0? Or should we rather target Spring Boot 3.4.0?

Remark: Personally I would prefer to keep the current 2.x version of log4j-to-slf4j in Log4j 3.x instead of releasing a 3.0.0 for that artifact (see this thread on dev@logging). This would certainly ease the upgrade of the log4j2.version property to 3.0.0, since it would not change anything in the default spring-boot-starter-logging artifact.

[wilkinsona]

3.3.0-RC1 is scheduled for next week. Depending on the nature of the changes that means we may only have a week to make any further changes. If it's a bug, we have longer as we can make the fix post RC1 or even in a subsequent maintenance release.