Improve Log4j Core Configuration File Detection for Version 3

[ppkarwasz]

Log4j Core 3 has undergone significant modularization and no longer uses optional parser dependencies. This change requires updates to Spring Boot's configuration file detection logic to properly support both Log4j Core 2 and 3.

Summary of Changes

• Updated configuration file detection
  Spring Boot now detects configuration formats also based on the presence of ConfigurationFactory implementations, instead of only relying on optional parser dependencies (as was the case in Log4j Core 2).

• Improved classloader usage for reflection
  Reflection logic now uses the classloader that loaded Log4j Core, rather than the one associated with the Spring Boot context, ensuring greater compatibility in modular environments.

• Adjusted configuration file lookup order
  The lookup now prioritizes configuration files specified via properties over automatically discovered ones, improving consistency with Log4j Core.

• Support for contextual configuration files
  Files named in the form log4j2<contextName>.<extension> are now also supported.

These changes ensure compatibility with Log4j Core 3 while preserving support for Log4j Core 2, improving Spring Boot's flexibility in detecting and loading user-defined logging configurations.

Note

The configuration file detection logic introduced here could potentially be moved into a future version of Log4j Core itself. For more context, see apache/logging-log4j2#3775.

[ronodhirSoumik]

wouldnt it better to keep those in log4j.properties file and use that here to make it more rebust

[ppkarwasz]

The fully qualified class names of the Log4j configuration factories and parsers are stable and unlikely to change, so I don't see a clear advantage in externalizing them to a Java properties file. Doing so would add complexity without providing much practical benefit in this context.

For a more robust and dynamic approach, it is possible to query Log4j’s ConfigurationFactory system directly to discover active factories and their supported file types. However, this mechanism would require relying on more Log4j internal classes and the way to retrieve all the ConfigurationFactorys changes between version 2.x and 3.x.

Note: If Spring Boot 4.x ends up depending on Log4j 2.26.x or newer, we could leverage the enhancements introduced in apache/logging-log4j2#3775 to make this process simpler and more robust. However, given the current timeline, it's unclear whether we will be able to finalize the release in time for inclusion.