No Spring Boot logging output with Log4J 2.25.0

[ianbrandt]

Description

If I update my Spring Boot project from Log4J 2.24.1 to 2.25.0 (no other changes), I no longer get logging output.

Per spring-projects/spring-boot#46035:

b23e9a5 is a breaking change from Spring Boot's perspective. We call LoggerContext.start(Configuration) on a LoggerContext in STARTED state. This used to result in setConfiguration(Configuration) being called. Since these changes in Log4j2, that no longer happens so Boot's configuration isn't applied. Perhaps we can do something differently that will work with both 2.25.0 and earlier versions but I think this should be investigated by the Log4j2 team in the first instance. I'll close this one for now, we can re-open it if that investigation identifies a change that could be made in Boot to tolerate the change in Log4j2's behavior.

Configuration

Version:

Log4J 2.25.0
Spring Boot 3.5.1

Operating system: MacOS 15.5 (presumably any)

JDK:

 % java --version
openjdk 21.0.7 2025-04-15 LTS
OpenJDK Runtime Environment Temurin-21.0.7+6 (build 21.0.7+6-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.7+6 (build 21.0.7+6-LTS, mixed mode, sharing)

Logs

Log4J 2.24.1
https://github.com/sdkotlin/sd-kotlin-spring-talks/tree/8d40d0c54e700adbc7c7609eb2b04a16223869ab

> Task :subprojects:app:run

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v3.5.1)

2025-06-19T10:14:37.901-07:00  INFO 65736 --- [           main] o.s.s.SpringBootAppKt                    : Starting SpringBootAppKt using Java 21.0.7 with PID 65736 (/Users/ianbrandt/Development/SDKotlin/sd-kotlin-spring-talks/subprojects/app/build/classes/kotlin/main started by ianbrandt in /Users/ianbrandt/Development/SDKotlin/sd-kotlin-spring-talks/subprojects/app)
2025-06-19T10:14:37.903-07:00  INFO 65736 --- [           main] o.s.s.SpringBootAppKt                    : No active profile set, falling back to 1 default profile: "default"
2025-06-19T10:14:38.107-07:00  INFO 65736 --- [           main] k.r.KClass                               : Config path: /Users/ianbrandt/Development/SDKotlin/sd-kotlin-spring-talks/subprojects/app/config
2025-06-19T10:14:38.107-07:00  INFO 65736 --- [atcher-worker-1] k.r.KClass                               : The current time is 2025-06-19T17:14:38.107189Z
2025-06-19T10:14:38.107-07:00  INFO 65736 --- [           main] k.r.KClass                               : Log path: /Users/ianbrandt/Development/SDKotlin/sd-kotlin-spring-talks/subprojects/app/logs
You've been scanned.
2025-06-19T10:14:38.128-07:00  INFO 65736 --- [           main] o.s.s.SpringBootAppKt                    : Started SpringBootAppKt in 0.395 seconds (process running for 0.625)
2025-06-19T10:14:38.129-07:00  INFO 65736 --- [           main] o.s.s.ResourcePrinter                    : classpath:/native-resource.txt content:
Testing native resources on MacOS.

2025-06-19T10:14:38.130-07:00  INFO 65736 --- [           main] o.s.s.ResourcePrinter                    : classpath:/custom-resource.txt content:
Testing custom resources.

BUILD SUCCESSFUL in 9s

Log4J 2.25.0
https://github.com/sdkotlin/sd-kotlin-spring-talks/tree/b15de4858a0c10ab9c267489b1b5a98cf1a9e10d

> Task :subprojects:app:run

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::                (v3.5.1)

You've been scanned.

BUILD SUCCESSFUL in 1s

That one "You've been scanned" line is a plain old println(): https://github.com/sdkotlin/sd-kotlin-spring-talks/blob/b15de4858a0c10ab9c267489b1b5a98cf1a9e10d/subprojects/app/src/main/kotlin/org/sdkotlin/springdemo/SpringBootApp.kt#L45.

Diff: sdkotlin/sd-kotlin-spring-talks@b15de48.

Reproduction

Not quite a minimal reproducer, but in case it's of any help:

https://github.com/sdkotlin/sd-kotlin-spring-talks/tree/b15de4858a0c10ab9c267489b1b5a98cf1a9e10d

gradlew :subprojects:app:run

[ppkarwasz]

Hi @ianbrandt,

Thank you for catching this and taking the time to report it!

Given the significance of the Spring Boot ecosystem, I've scheduled this issue for inclusion in the upcoming 2.25.1 release, which will specifically address integration issues across various environments. For more context, feel free to check out the 2.25.1 roadmap: #3766.

Much appreciated!

[wilkinsona]

Thanks very much, @ppkarwasz. If there's something that we (the Spring Boot team) should be doing differently when 2.25 (or a later version) becomes our default Log4j2 version, please let us know.

Edit: catching up on notifications, I've now seen spring-projects/spring-boot#46035 (comment). Thank you for the guidance.

[ppkarwasz]

Hi @wilkinsona,

Thanks — I’ve added some suggestions to the discussion in spring-projects/spring-boot#46035.

Spring Boot is one of the projects that makes the most extensive use of the API surface exposed by Log4j Core, and we’re very mindful of which methods are being used. We try to document these methods, so we can avoid surprises like the removal of ConfigurationFactory.getConfiguration(ConfigurationSource) in 2.7 — an experience we definitely don't want to repeat with Log4j Core 3. Apparently we missed one method 😉

That said, there are still some areas we’d like to revisit or better abstract. One example is Spring Boot’s current reliance on relatively internal classes like AuthorizationProvider and SslConfiguration. Ideally, these could be abstracted in a way that allows tighter integration with Spring Boot’s own mechanisms for managing secrets and credentials.

Our ShutdownCallbackRegistry could also benefit from tighter integration with Spring Boot, to ensure that the logging system is shut down last, after all other components have completed their cleanup. The current DefaultShutdownCallbackRegistry relies on JVM shutdown hooks, which do not guarantee any specific execution order. If I recall correctly, Spring Boot currently disables the default shutdown hook entirely — which makes sense, but also highlights the need for a more coordinated and flexible shutdown mechanism.

If you have time and are open to a deeper discussion, feel free to reach out via the email listed on my GitHub profile, or schedule a quick chat using my zeeg.me link.