Are there any reasons to use XML over properties files for Log4J configuration?
相关问题
- Delete Messages from a Topic in Apache Kafka
- Jackson Deserialization not calling deserialize on
- Illegal to have multiple roots (start tag in epilo
- How to maintain order of key-value in DataFrame sa
- StackExchange API - Deserialize Date in JSON Respo
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.
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.
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.
There's an interesting discussion on the merits of both in this blog. The section below is a quote from that blog:
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.