Advantages of using Logback over Log4j
Logback is a mature, widely used logging framework. It was designed by Ceki Gülcü, the same developer who created Log4j.
Logback is very well tested which makes it rock solid and reliable even under adverse conditions.
Logback comes with comprehensive documentation that is regularly updated.
Logback components are faster and have a smaller memory footprint as compare to Log4j 1.x.
Logback-classic component natively implements SLF4J, so calling the SLF4J logger class with logback-classic incur zero overhead.
Logback can automatically reload it's configuration file upon modification. The scanning process is quick and is capable of making millions of invocations per second across hundreds of threads.
Logback's FileAppender and RollingFileAppender can gracefully recover from any I/O failures. As a result, if a file server goes down for a while, you won't have to restart your program only to get logging to work again. The logback appender will transparently and swiftly recover from the previous error condition once the file server is restored.
Archived log files can be automatically compressed by RollingFileAppender. Compression is always done asynchronously, so your application isn't blocked for the duration of the compression, even if the size of the log files are large.
Old log archives can be automatically removed by setting the maxHistory property of TimeBasedRollingPolicy or SizeAndTimeBasedFNATP. Simply set the maxHistory property to 12 if your rolling policy requires monthly rollover and you want to store one year's worth of logs. Log files that have been archived for more than 12 months will be automatically deleted.
Multiple FileAppender instances running on different JVMs can safely write to the same log file in prudent mode. Prudent mode extends to RollingFileAppender with some restrictions.
Logback offers more filtering options than log4j 1.x. Assume you have a mission-critical application running on a production server. Because of the large number of transactions handled, the logging level is set to WARN, which only logs warnings and errors. Imagine you're dealing with a bug that you can recreate on the production system but can't reproduce on the test platform because of unidentified variations between the two environments (production/testing). With log4j 1.x, your only option is to set the logging level to DEBUG on the production system to try to figure out what's wrong. Unfortunately, this will result in a vast amount of logging data, which will make analysis difficult. More importantly, heavy logging can have an influence on your application's performance on the production system. However, with Logback, you can keep logging at the WARN level for all users except the one who is responsible for finding the problem, such as Danny. When Danny logs in, he will be logging at level DEBUG, while other users will be logging at level WARN. By adding four lines of XML to your configuration file, you can accomplish this feature.
The Logback's SiftingAppender can be used to separate logs by any runtime attribute. For example, SiftingAppender may split logs events based on user sessions, such that each user's log are saved in their own log file.
Developers frequently have to switch back and forth between multiple logback configuration files aimed at different environments, such as development, testing, and production. These configuration files have a lot in common and only differ in a few places. To avoid duplication, logback uses the <if>, <then>, and <else> components to conditionally process configuration files, allowing a single configuration file to target several environments.
The logback-access module, which is included with the logback distribution, integrates with Servlet containers like Jetty or Tomcat to provide comprehensive and robust HTTP-access log capability.
The Logback's stack trace includes packaging data when it prints an exception.
