I think what you propose makes a lot of sense. Ralph
> On Feb 25, 2025, at 9:16 AM, Piotr P. Karwasz <pi...@mailing.copernik.eu> > wrote: > > 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 >
