Hi Ralph, On 25.02.2025 14:36, Ralph Goers wrote:
Just an FYI - in Spring Boot 3 if you specify an override file that is not present the application will fail to start. This behavior is different then what log4j-spring-boot does. It seems that if you include the log4j-spring-boot jar then the error is avoided.
IMHO the `Log4j2LoggingSystem` (both ours and the one in Spring Boot 3) has a lot of aspects that can be improved:
1. This `LoggingSystem` is enabled each time `log4j-core` is on the classpath. It should also check that `log4j-core` has been selected as Log4j API provider, otherwise many `ClassCastException`s will follow.
2. Each time a `LoggerContext` is needed `LogManager.getContext(false)` is called. This means that the logger context used by `initialize()` and `cleanUp()` are not necessarily the same. Users have reported a couple of times that `cleanUp()` will start a new logger context if the old one was already closed. If `cleanUp()` is called during the JVM shutdown, the Log4j API will return a `SimpleLoggerContext` and a `ClassCastException` will occur.
3. Spring Boot apparently allows a different `LoggingSystem` per class loader (it passes a class loader argument to the `LoggingSystemFactory`), but the argument is not passed down to the Log4j API, so we can not use our `ContextSelector` to create an appropriate context. One of the consequences is that a Spring Boot application running in a Log4j Core-enabled Tomcat, will try to modify to logger levels of a logger context shared by all the apps on the server.
4. The structured logging feature they implemented in version 3.4.x, totally ignores all the work Volkan and others put into JTL. We can probably reimplement it more efficiently by not trying to reinvent the wheel.
If you are interested, we could probably create a GitHub project and take `Log4j2LoggingSystem` for a spin. If we end up with a better result, we can push it back to Spring Boot or even bring it back to Log4j.
Piotr
