ppkarwasz opened a new issue, #1430:
URL: https://github.com/apache/logging-log4j2/issues/1430
## 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](https://stackoverflow.com/q/75667479/11748454).
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
