Only recently began to use Logback in the project, there is a kind of encounter feeling, because it is very easy to meet my several needs:
1. Simple configuration, easy to start
2. A log file in which only one level of log
3. Multiple different logs can be specified in a class, and each log file that is generated contains only its own content
4. You can turn off or open a log of a few packages, and you can set up different packages to use different log levels.
first, ease of use
The ease of use of logback is that you can output logs in the console by simply following two lines:
Logger Debuglogger = Loggerfactory.getlogger (Myclass.class);
Logger.info ("This is a log");
When the program runs, Logback looks for the default profile Logback.xml or Logback-test.xml file, and if not, uses the default configuration to print the log to the console. The following is a simple configuration file (http://logback.qos.ch/manual/configuration.html):
<configuration>
<appender name= "STDOUT" class= "Ch.qos.logback.core.ConsoleAppender" >
<!-- Encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default-->
< Encoder>
<pattern>%d{hh:mm:ss. SSS} [%thread]%-5level%logger{36}-%msg%n</pattern>
</encoder>
</appender>
< Root level= "Debug" >
<appender-ref ref= "STDOUT"/>
</root>
</configuration>
second, log level limit
In most log tools, levels are transitive, for example, if the log output level is specified as debug, then the info, error level log also appears in the log file. This default to the debugging of the program brings a lot of trouble. In Logback, the output level of the log can be strictly restricted by the filter in appender :
<filter class= "Ch.qos.logback.classic.filter.LevelFilter" >
<level>INFO</level>
< onmatch>accept</onmatch>
<onMismatch>DENY</onMismatch>
</filter>
In the above settings, only the log content of level info is present in the file.
three, the same class contains a different log
Sometimes a class may require different log information to be printed, for example, some for debugging, some for recording changes in some parameters in the program's operation, and so on. At this point, you can declare different logs by using the following statement:
Logger Debuglogger = Loggerfactory.getlogger (myclass.class);
Logger Monitorlogger = Loggerfactory.getlogger ("Monitor");
Then specify a different output file in the configuration file (Debuglogger uses the default configuration):
<appender name= "Monitor" class= "Ch.qos.logback.core.rolling.RollingFileAppender" >
<file>${ log.dir}/monitor.log</file>
<encoder>
<pattern>%d{yyyy-mm-dd HH:mm:ss. SSS}:%m%n</pattern>
</encoder>
<filter class= " Ch.qos.logback.classic.filter.ThresholdFilter ">
<level>INFO</level>
</filter>
<rollingpolicy class= "Ch.qos.logback.core.rolling.TimeBasedRollingPolicy" >
<filenamepattern >${log.dir}/sensitive.log.%d{yyyy-MM-dd}</fileNamePattern>
</rollingPolicy>
</ appender>
<logger name= "Monitor" additivity= "false" level= "INFO" >
<appender-ref ref= "monitor "/>
</logger>
This is done by setting
additivity= "false"Prevent content from being passed up in the monitor, otherwise it will be displayed in the default log.
Four, accurate control log application range
In program debugging, it is often the case that the error is only in one or several classes or packages, so you only need to open the debug level log in these classes or packages. In previous projects, when using spring and Hibernate, once the debug-level log was turned on, the debug information for the program itself was overwhelmed by the large logs of spring and hibernate, greatly reducing the efficiency of debugging. And Logback makes it all simpler:
<logger name= "org" level= "ERROR"/>
This line sets all the log levels below the Org package to error and will not disturb our debug.