Simplify Log4J2LoggingSystem

[ppkarwasz]

This change leverages the major Spring Boot version bump to streamline and harden Log4J2LoggingSystem in two key areas:

1. Association with LoggerContext

Previously, each method fetched the LoggerContext directly from LogManager and cast it to o.a.l.l.core.LoggerContext. This approach introduced several issues:

• ClassCastException risks:

  • When Log4j Core is on the classpath but not the active implementation (e.g. when log4j-to-slf4j is used).
  • During shutdown, when LogManager may return a SimpleLoggerContext (see SpringApplicationShutdownHook throws ClassCastException when use log4j2 #26953).

• Unexpected reinitialization: If the logger context had already been stopped, Log4J2LoggingSystem would trigger creation of a new context, even mid-shutdown.

2. Configuration format detection

Configuration file detection was previously hardcoded in Log4J2LoggingSystem, which limited flexibility:

• Harder to support additional configuration formats.
• Coupled Spring Boot to internal Log4j Core classes such as AuthorizationProvider.

This change now delegates configuration resolution to Log4j Core via: ConfigurationFactory.getConfiguration(LoggerContext, String, URI, ClassLoader)

This reduces reliance on internal APIs and allows Log4j Core to handle configuration formats and factories more naturally.

Summary

• Avoids fragile casts and unintended logger context reinitializations.
• Delegates configuration handling to Log4j Core for improved extensibility and reduced internal API usage.

Notes

• Build issues: On my local setup, the build fails with NullAway errors in classes unrelated to this PR. Even when replicating the CI environment, I was unable to achieve a successful local build.
• Draft status: This PR is marked as a draft because it currently lacks additional tests. Since many changes simply delegate behavior to Log4j Core, I’d appreciate feedback on what tests should remain in Spring Boot and which ones should instead be added to Log4j Core.
• Breaking changes (intentional): This PR intentionally removes the public constructor and the protected loadConfiguration methods to enable further refactorings in Spring Boot 4.1.x. For example, once Add getConfiguration method for multiple URIs apache/logging-log4j2#3921 is included in Log4j 2.26.0, configuration merging could also be delegated to Log4j Core, further reducing Spring Boot’s dependency surface on internal Log4j Core APIs.

[wilkinsona]

On my local setup, the build fails with NullAway errors in classes unrelated to this PR. Even when replicating the CI environment, I was unable to achieve a successful local build.

You need to use Java 24 (or ideally 25) for NullAway to work correctly due to javac bugs in Java 23 and earlier.

[ppkarwasz]

Thanks, I'll try JDK 25 to fix the failures reported by the CI and add some unit tests.

[danish-ali]

In loadOverride(...), I see a FileNotFoundException being caught and returned null, but there might be other I/O errors upstream. Should we guard more broadly or document the exception semantics?