Hi Ralph, On Thu, 11 Jan 2024 at 01:38, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I fixed two bugs. One was reported against 2.x ages ago. The second was first > reported in the Spring issue. > > Yes, they can be ported to 2.x but if we release 3.0.0 in the next couple of > months I would prefer to tell users just to upgrade since 3.x specifically > targets the environment Spring 3.x uses.
Both solutions are fine with me. I looked at the current Spring Boot code and the new methods you introduced with a comment "Used in Spring Boot" are not used there yet. Is it something you are currently working on? If you introduce them, we'll need to make a choice: * either Spring Boot 3.3.x will support only Log4j 3.x, * or we backport all changes and only use Java types and methods that are present in both releases. The custom Spring Boot configuration file detection logic[2] already fails with Log4j Core 3.x (except JSON and XML, the remaining config formats require an additional Log4j dependency), so if they decide to switch to Log4j 3.x in Spring Boot 3.3.x, we can double-check that the Log4j types they use ([1]) are really something we consider a public API. Piotr [1] https://github.com/spring-projects/spring-boot/blob/5b6e3fab2cb7355d1053c71d0b4411687f463aaa/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/log4j2/Log4J2LoggingSystem.java#L32-L53 [2] https://github.com/spring-projects/spring-boot/blob/5b6e3fab2cb7355d1053c71d0b4411687f463aaa/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/logging/log4j2/Log4J2LoggingSystem.java#L137-L162
