Reasons to migrate from log4j to Logback

reasons to migrate from log4j to Logback

Url:http://www.oschina.net/translate/reasons-to-prefer-logbak-over-log4j?p=2#comments English Original: Reasons to prefer Logback over log4j

Sub recommended 20 days ago (total 10 paragraphs, translation completed 04-02)

Participation in Translation (4 people): Enixyu, Rslee, MISCHIEFQLF, FBM

In terms of design and implementation, Logback has relatively many improvements relative to log4j. But although it is difficult to count them all, here are some reasons why you choose Logback rather than log4j. Keep in mind that Logback and log4j are very similar in concept, and they are all created by the same group of developers. So if you are already familiar with log4j, you can also get started quickly logback. If you like using log4j, you might be hooked on using Logback. faster execution Speed Based on our previous work on log4j, Logback rewrote the internal implementation, which can even be up to 10 times times faster than before for certain scenarios. While ensuring that logback components are faster, they require less memory at the same time.

Rslee Translated 17 days ago 0 Person Top Top translation of good Oh!

full test Logback After a few years, countless hours of testing. Although log4j is also tested, the logback is more fully tested and not at the same level as log4j. We believe that this is the most important reason why people choose Logback rather than log4j. It is hoped that even in bad conditions, your diary frame will remain stable and reliable. The Logback-classic very naturally implements the SLF4J Logback-classic in the natural implementation of the SLF4J. When you use Logback-classic as the underlying implementation, there is no need to consider the problem with the lf4j journaling system. Further, since Logback-classic strongly recommends using SLF4J as the client journaling system, if you need to switch to log4j or something else, you only need to replace a jar package, and you do not need to change the code implemented through the slf4j API. This can greatly reduce the amount of work required to change the journaling system.

MISCHIEFQLF translated 10 days ago 0 people top Top   translation is good!

Extending documents Logback is accompanied by detailed and constantly updated documentation. using an XML configuration file or groovy The traditional way to configure Logback is through an XML file. In the documentation, most of the examples are in XML syntax. However, for Logback version 0.9.22, configuration files written with groovy are also supported. More intuitive, coherent and short syntax than the Xml,groovy style profile. Now, there is a tool that automatically migrates the Logback.xml files to Logback.groovy.

Enixyu Translated 16 days ago 2 person Top Top translation of good Oh!

automatically reload configuration files Logback-classic can be automatically re-loaded after the configuration file has been modified. This scanning process is fast, no resource contention, and can be dynamically extended to support millions of calls per second between hundreds of threads. It is well-integrated with the application server and is common in the JEE environment because it does not invoke the creation of a separate thread to do the scanning. gracefully recover from I/O errors Fileappender and its subclasses, including Rollingfileappender, can gracefully recover from I/O errors. So, if a file server goes down temporarily, you don't need to restart your app anymore, and the log function works. When the file server resumes work, the Logback related Appender will transparently and quickly recover from the previous error.

Enixyu Translated 16 days ago 1 person Top Top translation of good Oh!

automatically purge old log archive By setting timebasedrollingpolicy  or &NB Sp SIZEANDTIMEBASEDFNATP  maxHistory  Properties, you can control the maximum number of log archive files. If your rollback strategy is rolled back monthly, and you want to keep a log for one year, simply set the Maxhistory property to 12. Archived log files that are 12 months old will be automatically purged. automatically compress archived log files The Rollingfileappender can automatically compress the archive log file during a rollback operation. Compression is usually performed asynchronously, so even large log files are not blocked by your application.

enixyu translated 16 days ago 1 people top Top   translation is good!

Caution mode In discreet mode, multiple Fileappender instances running in multiple JVMs can be safely written to a unified day Log files. The caution mode can be applied to rollingfileappender under certain restrictions. Lilith Lilith is a record and access Event Viewer for Logback. It is equivalent to log4j's chainsaw, but the Lilith design is designed to handle a large number of log records. Conditional handling in configuration Files Developers typically need to transform logback profiles in different target environments, such as development environments, test environments, and production environments. These profiles are roughly the same, except that some parts will be different. To avoid duplication, Logback supports conditional processing in profiles by using <if>,<then> and <else>, and the same configuration file can be used in different environments.

enixyu translated 16 days ago 0 people top Top   translation is good!

Filter Logback has a much richer filtration capability than log4j. For example, let's assume that there is a fairly important commercial application deployed in the production environment. Given that a large amount of transaction data needs to be processed and the logging level is set to warn, only warnings and error messages will be logged. Now, imagine that you've encountered a bug in your development environment, but it's hard to find it in a test platform because of the unknown differences between some environments (production/test environments).

Enixyu Translated 16 days ago 0 Person Top Top translation of good Oh!

With log4j, you can only choose to reduce the level of logging in the production system to debug to try to find the problem. Unfortunately, this generates a lot of logging, making analysis difficult. More importantly, extra logging can affect the performance of your production environment. With Logback, you can choose to keep only the warn level of logs for all users, except for a user, such as Alice, who is the relevant user of the problem. When Alice logs on to the system, she is logged at the debug level, while the other user still logs the log at the warn level. This feature can be added by adding 4 rows to the XML in the configuration file. Please find the mdcfilter in the relevant section

Enixyu Translated 16 days ago 0 Person Top Top translation of good Oh!

Siftingappender The Siftingappender is an all-rounder add-on. It can separate (or filter) logs based on any given real-time attribute. For example, Siftingappender can separate log events based on user sessions, so that a separate log file can be created for each user. The stack trace information contains the data for the package When Logback prints an exception, the stack trace information will contain the relevant data for the package. The following is a stack of information generated through Logback-demo: 14:28:48.835 [btpool0-7] INFO c.q.l.demo.prime.primeaction-99 is not a valid value java.lang.exception:99 is invalid At Ch.qos.logback.demo.prime.PrimeAction.execute (primeaction.java:28) [Classes/:na] at Org.apache.struts.action.RequestProcessor.processActionPerform (requestprocessor.java:431) [Struts-1.2.9.jar : 1.2.9] at org.apache.struts.action.RequestProcessor.process (requestprocessor.java:236) [struts-1.2.9.jar:1.2.9] At Org.apache.struts.action.ActionServlet.doPost (actionservlet.java:432) [struts-1.2.9.jar:1.2.9] at Javax.servlet.http.HttpServlet.service (httpservlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12] at Org.mortbay.jetty.servlet.ServletHolder.handle (servletholder.java:502) [jetty-6.1.12.jar:6.1.12] at Ch.qos.logback.demo.UserServletFilter.doFilter (USERSERVLETFILTER.JAVA:44) [Classes/:na] at Org.mortbay.jetty.servlet.servlethandler$cachedchain.dofilter (servlethandler.java:1115) [Jetty-6.1.12.jar : 6.1.12] at Org.mortbay.jetty.servlet.ServletHandler.handLe (servlethandler.java:361) [jetty-6.1.12.jar:6.1.12] at Org.mortbay.jetty.webapp.WebAppContext.handle ( webappcontext.java:417) [jetty-6.1.12.jar:6.1.12] at Org.mortbay.jetty.handler.ContextHandlerCollection.handle ( contexthandlercollection.java:230) [jetty-6.1.12.jar:6.1.12] From the above information, you can find that this app uses Struts 1.2.9 and is deployed using jetty 6.1.12. So, the stack trace information will quickly tell the reader that the class on which the exception occurred is also the version of the package and package. When your client sends you a stack trace message, as a developer, you don't need to let them tell you the version of the package they're using. This information is already included in the stack trace information. For more information, refer to "%xthrowable" conversion word. This feature can be very helpful in explaining that some users mistakenly think this is the function of the IDE.

Enixyu Translated 16 days ago 0 Person Top Top translation of good Oh!

The logback-access module, which provides the ability to access logs via HTTP, is an integral part of Logback Last but not least, as part of the Logback release package, the Logback-access module can be integrated with jetty or tomcat, providing a very rich and powerful ability to access logs through HTTP. Because the Logback-access module is part of the initial design of the logback, all of the features logback-access your favorite Logback-classic modules are also available. Concluding remarks We have given a lot of reasons to choose Logback rather than to choose log4j. In short, since Logback is built on the log4j we built earlier, Logback can be said to be a better log4j.