|
Bringing this topic back up before I plan any code changes, I'd like to elaborate on the idea. Right now, configuration done via the normal config file system is rather well supported in the documentation. One of the key improvements in Log4j 2's configuration format was getting rid of the need to specify internal class names to configure plugins. This feature request follows a similar philosophy in simplifying the global Log4j 2 settings that are normally specified as system properties or through a log4j2.component.properties file on the classpath. System property settings are documented all over the manual where appropriate, but the general system of how to use them other than as command line flags is not very well explained.
What I'd like to propose here, besides simplifying the base naming scheme and supporting them all (along with updating the documentation to normalize on the prefix log4j2. as discussed above), would be supporting a general property name format like such. All the following property names would be equivalent:
-
log4j.configurationFile
-
log4j2.configurationFile
-
Log4jConfigurationFile
-
org.apache.logging.log4j.configurationFile
-
LOG4J_CONFIGURATIONFILE
-
LOG4J_CONFIGURATION_FILE
![]()
-
Log4j-configurationFile
-
Log4j-ConfigurationFile
![]()
-
log4j.configuration.file
![]()
The idea here being that dots, dashes, and underscores should all be equivalent (underscores being supported for allowing environment variables to be used instead of system properties in a 12factor system, and dashes being added possibly to allow for alternate styles to be used, but I have no personal request for that other than completeness); properties could either be case-insensitive or we could support a system where CamelCaseWords are treated the same as camel.case.words or CAMEL_CASE_WORDS (so, somewhat case insensitive, but after parsing into words); and this would in general provide the possibility to inject configuration in a cloud environment through any arbitrary configuration system (although supporting environment variables in addition to system properties would handle the majority of cases; it's not like global settings from PropertiesUtil are reconfigurable at runtime, so supporting hot-reload via some configuration management server doesn't make sense here).
I also have in my notes that it may be useful to support slashes as well for a JNDI-style configuration (and potentially supporting property lookup via JNDI), but that would be an open feature request as I don't personally use JNDI anymore (I generally stick to environment variables for options that change per environment and system properties for things that change per application).
Things that this is not:
-
Support for complex data types (i.e., we'd only support primitives and strings as we already do).
-
Reconfigurable global properties (not only would this be very difficult to support correctly, I don't even see how this would be useful for a user).
-
A public API for writing a configuration system (just use a dedicated library like one mentioned below).
-
A replacement for the plugin configuration system (in fact, the less we rely on global settings, the better).
-
Support for similar naming schemes in plugins (e.g., adding dash support in tag names similar to appender-ref).
In my own applications, I would normally just use some sort of configuration library like Commons Configuration, Archaius, or HOCON, but as Log4j is a low level library, this isn't an option.
|
