ppkarwasz commented on issue #3775:
URL: 
https://github.com/apache/logging-log4j2/issues/3775#issuecomment-3033483293

   > The shared use case is interested in supported file formats, yet the 
proposed solution returns supported file locations, which has its own 
complications. Why don't we return support file formats instead? What is the 
use case for returning supported file locations?
   
   The supported configuration file formats vary not only by syntax (indicated 
by file extensions), but also by the Log4j major version (implied by the 
filename prefix). For example:
   
   - `log4j2.xml` — Log4j 2 configuration in XML format  
   - `log4j.xml` — Log4j 1 configuration in XML format
   
   This is why I initially thought to list the supported configuration file 
locations, instead of just the supported extensions.
   
   However, support for these formats is implemented more as a compatibility 
workaround than a clean abstraction:
   
   - To use the Log4j 1 format, the configuration must be specified using the 
[legacy `log4j.configuration` system 
property](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#log4j.configuration).
   - When using the `log4j2.configurationFile` property or providing a 
configuration `URI` programmatically, behavior depends on the 
[`log4j1.compatibility` 
property](https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html#log4j1.compatibility):
     - If `true`, files with `.xml` or `.properties` extensions are handled by 
Log4j 1 configuration factories.
     - If `false`, those same files are parsed using Log4j 2 configuration 
factories.
   
   I’m not sure it’s a good idea to expose this kind of ambiguity to end users. 
Given that, I agree — it probably makes more sense to introduce a method like 
the following:
   
   ```java
   public abstract class ConfigurationFactory {
   
       /**
        * Returns an ordered list of supported configuration file extensions.
        *
        * <p><strong>Warning:</strong> This method should only return extensions
        * supported by configuration factories for the current Log4j version. 
It must not include
        * legacy configuration factories.</p>
        */
       public abstract String[] getSupportedExtensions();
   }
   ```
   
   


-- 
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]

Reply via email to