logging-log4j2
logging-log4j2 copied to clipboard
Log4j ignores system property configurationFile
Description
According to the doumentation, Log4j will inspect the "log4j.configurationFile" system property and, if set, will attempt to load the configuration using the ConfigurationFactory that matches the file extension. In version 2.x this property was named "log4j2.configurationFile". Either way, Log4j seems to ignore this system property. Instead it is sensitive to a system property named "log4j2.*.Configuration.file".
Is this a documentation issue only? How should this be used in version 3.x? Why case sensitive Configuration?
Configuration
Version: 3.0.0-beta2
Operating system: 5.15.133.1-microsoft-standard-WSL2 #1 SMP x86_64 GNU/Linux
JDK: openjdk 17.0.9 2023-10-17
Logs
In addition to above described issue, loading a YAML configuration works with version 3.0.0-beta1 but fails with 3.0.0-beta2:
[Fatal Error] log4j2.yml:1:1: Content is not allowed in prolog.
ERROR StatusLogger Error parsing /config/log4j2.yml
org.xml.sax.SAXParseException; systemId: file:///config/log4j2.yml; lineNumber: 1; columnNumber: 1; Content is not allowed in prolog.
at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:262)
at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:342)
at org.apache.logging.log4j.core.config.xml.XmlConfiguration.<init>(XmlConfiguration.java:88)
Apparently with the latest version a XmlConfiguration object is created even if the file extension is yml.
@tglaeser,
Thank You for beta-testing the 3.x release series.
In 3.0.0-beta2 we moved the YAML configuration factory to a separate artifact (cf. #2142):
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-config-yaml</artifactId>
<version>3.0.0-beta2</version>
</dependency>
The goal we want to achieve with Log4j 3.x is to eliminate all optional dependencies: in order to "activate" the YAML configuration it is no longer necessary to find out which dependencies are necessary, but it is enough to include log4j-config-yaml in your classpath.
Due to the increasing number of artifacts, you might also want to include log4j-bom in the dependency management section of your build tool. Its Maven coordinates are:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>3.0.0-beta2</version>
<type>pom</type>
</dependency>
The XML configuration factory is a "catch-all" factory that reads files with any extension. @rgoers: shouldn't we remove this "catch-all" behavior in 3.0.0? It seems to cause more problems than it solves.
OK, that makes sense; what about the main topic: How to set the configuration file system property?
Log4j 3.x will follow the Property Enhancement proposal, that allows to have a per-context configuration even with Java system properties.
Currently we are both refactoring the properties implementation (#2290) and improving the docs. At the moment the officially supported configuration property is:
log4j2.*.Configuration.file
but the old log4j2.configurationFile is also supported. However the details might vary while we approach 3.0.0.
Personally I am not a big fan of the * in a property name (might need escaping on the command line), the 2 in log4j2 (the version is 3.x) and the file part (the property actually accepts either an URI, a file name or the name of a resource. My personal favorite for 3.x would be:
log4j.Configuration.location
But the notation is inconsistent; some parts of the system property name start with lower case while other start with upper case and the overall system property name is case sensitive. That will cause confusion I think.
using log4j-config-yaml:3.0.0-beta2
[Fatal Error] log4j2.yml:1:1: Content is not allowed in prolog.
|#]
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:262)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:339)
@sysmat,
- Are you using version
3.0.0-betaforlog4j-config-yaml,log4j-coreandlog4j-api? - Are you using the originally package artifacts or are you making an uberjar of all your dependencies?