ppkarwasz opened a new issue, #3775:
URL: https://github.com/apache/logging-log4j2/issues/3775
**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()`](https://docs.spring.io/spring-boot/api/java/org/springframework/boot/logging/AbstractLoggingSystem.html#getStandardConfigLocations%28%29)
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.
```java
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.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
