Log4j 2 configuration: XML vs JSON?

Question

Apache manual simply states: "

Configuration of Log4j 2 can be accomplished in 1 of 4 ways:
Through a configuration file written in XML, JSON, or YAML.
Programmatically, by creating a ConfigurationFactory and Configuration implementation.
Programmatically, by calling the APIs exposed in the Configuration interface to add components to the default configuration.
Programmatically, by calling methods on the internal Logger class.

Id' like to hear if there's visible trends in favoring one of these 4 ways?
Behind this question is the shift of Log4j (version 1) configuration practice from .properties files to XML format. It's pretty frustrating to search for answers for a problem and receive the right answer but not quite with configuration method you are using.

I have a new log4j (version 2) project coming up and I'd like to use JSON as a configuration format against the default XML way of doing it (reason: aesthetics and slight performance advantage(?) ).

Will I encounter problems or not get as many features if I choose the JSON configuration format over XML?

Any reasons to use programmatic approach instead of a static configuration file?

Use case would be (ideally) that single configuration file is read by the application server (from some file path on the server). This single .json file would then be used to apply log levels per application and produce at least 3 different logs (general, error, custom log level) per application. There's less than 10 applications designed to run on a server.

Answer 1

There is no performance advantage or disadvantage to using XML or JSON. Personally I prefer XML for these two reasons: (but they are not huge problems so of course it is up to you...)

• JSON configuration requires the Jackson jar files in the classpath, so there's an extra dependency. XML uses the XML parser built in to Java.
• All examples in the log4j2 manual use XML, not JSON, so you'll need to convert the syntax. If you choose XML you can copy-and-paste from the manual.

I would not recommend programmatic configuration. It is more complex and depends on implementation specifics, which may change in the future. IMHO it will be a bunch of work for little or no benefit.

For the use case you describe, you can use system properties in your configuration so multiple apps can share the same config but log to different locations by varying the property values for each application.

---

UPDATE:

Log4j2 added an API for programmatic configuration in a later release. This API doesn’t expose implementation details. However it’s mostly suitable for configuring from scratch. If you want to modify an existing configuration you will need to use implementation classes.