Summary:

Introduce a method in Log4j Core to list the configuration file locations currently supported by the deployment.

🔍 Motivation

The logic for determining which configuration file formats are supported differs between Log4j Core 2.x and 3.x:

• In 2.x:
  All ConfigurationFactory implementations reside in log4j-core, but some depend on optional dependencies (JSON and YAML), meaning not all formats are necessarily available at runtime.

• In 3.x:
  Each ConfigurationFactory is moved to its own module/artifact. These factories are activated as soon as their respective artifact is on the classpath.

  • One exception is XmlConfigurationFactory, which remains in log4j-core, but can only be used if:

    • The java.xml module is present (on the JVM), or
    • An external DocumentBuilderFactory is available (e.g., on Android where the default factory lacks required options)

This evolving behavior makes it difficult for external systems to know which config files Log4j Core will actually process.

📦 Use Case

Spring Boot needs a reliable way to determine which configuration file formats are supported by the current Log4j Core deployment, in order to correctly customize its configuration file search logic (e.g., to support files like log4j2-spring.xml).

Currently, the getStandardConfigLocations() and getSpringConfigLocations() methods in Log4j2LoggingSystem rely on hardcoded assumptions about which formats are supported. This approach is fragile and tightly coupled to specific versions of Log4j Core.

This hardcoding becomes particularly problematic with Log4j Core 3:

• For example, Spring Boot will not look for a log4j2-spring.json configuration file if the Jackson library is missing, despite JSON being a supported format in Log4j Core 3.
• Conversely, it may attempt to load a log4j2-spring.properties file even when the log4j-config-properties module is not present, resulting in configuration failure.

✅ Proposed Solution

Introduce a public API in Log4j Core that returns the set of actively supported default configuration file locations, based on the currently available ConfigurationFactory implementations.

One option would be to add a method like getDefaultConfigLocations() to the ConfigurationFactory class. This method would return the list of standard file names (e.g., log4j2.xml, log4j2.json, etc.) that the factory is capable of processing in the current runtime environment.

public abstract class ConfigurationFactory {

    /**
     * Returns the default configuration file names that this factory supports,
     * given the specified context name. For example:
     * ["log4j2.xml", "log4j2" + contextName + ".xml"]
     */
    public abstract String[] getDefaultConfigLocations(String contextName);
}

Each factory would return only the file names it can currently handle — based on available modules, libraries, or runtime conditions (e.g., presence of java.xml for XML parsing) and the default ConfigurationFactory would just aggregate the results of all available configuration factories.

Note: As discussed in #1501, it may be worth adding a warning mechanism when a configuration file matching the pattern log4j2<contextName>.<extension> is present on the classpath, but no active ConfigurationFactory is available to handle that file type.