Log4j 2 config: XML vs JSON?
The Apache manual simply states: "
Log4j 2 configuration can be done in one of 4 ways:
Through a configuration file written in XML, JSON, or YAML.
Programmatically by creating an implementation of ConfigurationFactory and Configuration.
Programmatically by calling the APIs exposed in the config interface to add components to the default config.
Programmatically by calling methods in the inner class Logger.
I'd like to hear if there are any visible trends in favor of one of these four ways?
Behind this question is the migration of Log4j (version 1) configuration practices from .properties files to XML. It's pretty frustrating for finding answers to a problem and getting the right answer, but not quite using the setup method you're using.
I have a new log4j project (version 2) and I would like to use JSON as the configuration format versus the default XML method (reason: aesthetics and slight performance advantage (?)).
Am I running into problems or don't get as many features if I choose the JSON over XML configuration format?
Any reasons for using a programmatic approach instead of a static config file?
The use case would (ideally) have a single config file read by the application server (from some file path on the server). This single .json file will then be used to apply log levels for each application and generate at least 3 different logs (general, error, custom log level) for each application. There are less than 10 applications designed to run on a server.
source to share
There is no performance advantage or disadvantage for using XML or JSON. I personally prefer XML for these two reasons: (but they aren't huge problems, so of course it's up to you ...)
- JSON configuration requires jar json files on the classpath, so there is an additional dependency. XML uses the XML parser built into Java.
- All examples in the log4j2 tutorial use XML, not JSON, so you will need to convert the syntax. If you choose XML, you can copy and paste from the manual.
I would not recommend a programmatic configuration. This is more complex and depends on implementation specifics that may change in the future. IMHO this will be a bunch of work that will be of little use.
In this case, you can use system properties in your configuration so that multiple applications can use the same configuration but write to different locations by changing property values for each application.
source to share