StackOverflowException in Logger.isEnabled with Spring Boot 3 + Tomcat

[ppkarwasz]

Description

Tomcat calls Logger.isEnabled at the beginning of its ClassLoader#loadClass implementation.

If the method requires to load additional classes (e.g. org.apache.logging.log4j.core.Filter.Result) an infinite recursion occurs.

Reproduction

• configure Tomcat to use Log4j 2.x as server's logging framework,
• add a Spring Boot 3 application without Log4j2 jars,
• a stack overflow occurs.

Details

This issue was first reported in this StackOverflow question.

The problem occurs because:

1. If no logger context exists for a given classloader and configLocation == null the ClassLoaderContextSelector returns the logger context for the parent classloader. This is what happens in most LogManager.getContext calls;
2. Spring Boot adds a class from the webapp classloader as global filter to the logger context's configuration;
3. Tomcat calls Logger.isEnabled at the beginning of ClassLoader#loadClass hence it triggers the loading of all classes used by the global filter. This process uses the webapp classloader, hence the recursion.

[rgoers]

I think this problem is more general than you are making it out to be. Anytime there is a sequence of
app-> jul -> log4j -> 3rd party -> jul
there will be an infinite loop. We need to prevent that by detecting recursion in ApiLogger.

In this case, isLoggable should detect the recursion and return false.

[ppkarwasz]

I am closing this, since it was fixed in Spring Boot 3.1.11 and 3.2.5.