Why chose XML over properties files for Log4J configuration?

Question

Are there any reasons to use XML over properties files for Log4J configuration?

Solution 1

There's an interesting discussion on the merits of both in this blog. The section below is a quote from that blog:

Properties can be defined by a properties file or by an XML file. Log4j looks for a file named log4j.xml and then for a file named log4j.properties. Both must be placed in the src folder.

The property file is less verbose than an XML file. The XML requires the log4j.dtd to be placed in the source folder as well. The XML requires a dom4j.jar which might not be included in older Java versions.

The properties file does not support some advanced configuration options like Filters, custom ErrorHandlers and a special type of appenders, i.e. AsyncAppender. ErrorHandlers defines how errors in log4j itself are handled, for example badly configured appenders. Filters are more interesting. From the available filters, I think that the level range filter is really missing for property files.

This filter allows to define that a[n] appender should receive log messages from Level INFO to WARN. This allows to split log messages across different logfiles. One for DEBUGGING messages, another for warnings, ...

The property appender only supports a minimum level. If you set it do INFO, you will receive WARN, ERROR and FATAL messages as well.

---

To address the comments on my original answer: The italics are my emphasis. For the purposes of the tutorial the author has chosen to gloss over, or unintentionally omitted that the properties or xml need only be on the classpath rather than needing to be in the src folder. A simple way to add them to the classpath is to add them to the src folder, so for the purpose of the tutorial that was obviously deemed sufficient.

None of this is directly relevant to the question asked or the intention of the answer, which is to discuss the merits or otherwise of using xml files to configure log4j. I consider that the rest of the quote is relevant and useful to those looking to make an informed choice.

Solution 2

log4j is gradually moving to XML so properties is the legacy format.

Some new features can only be configured in XML. I was forced to switch to XMl because I need to use TimeBasedRollingPolicy.

However, XML is so verbose. I still use properties whenever I can.

Solution 3

Perf4j (http://perf4j.codehaus.org) is a very nice performance monitoring system, which is configured alongside log4j and works in conjunction to it and requires log4j.xml files.
So, if you plan on using perf4j (I'd recommend) then an xml format is required.

Solution 4

Well, one thing you can only do in an xml configuration is to set up a logger to use buffering (using the org.apache.log4j.AsyncAppender).

If you need more functionality, however, you might also want to look at logback, which contains a number of other improvements over log4j.

View more solutions

Comments

[ZZ Coder]

What do you mean by "src folder"? The configuration file can be placed anywhere in the classpath or anywhere if you specify the location via log4j.configuration.

[Rich Seller]

Those are not my words, it's a quote from the blog. Read the reference for context

[hohonuuli]

The above information is not correct. As Zhihong mentioned, the log4j.xml or log4j.properties file just need to be put in the classpath. Also, the log4j.dtd is included in the log4j.jar file (at least the last few versions); so you do not need to worry about including it in your application

[Karsten R.]

Since version 2.4 you can use log4j2.properties ( logging.apache.org/log4j/2.x/manual/… ). E.g. see this example: stackoverflow.com/a/50397001/5718513

[brianary]

The blog post appears to be gone. The properties file syntax is absolutely not less verbose, since each property name has to be fully qualified: appender.console.layout.type = JSONLayout appender.console.layout.compact="true" is longer than <JSONLayout compact="false"/> (but I can maybe see why Java programmers would find the former more familiar).