logback.xml

阅读更多

Let us begin by discussing the initialization steps that logback follows to try to configure itself:

1. Logback tries to find a file called logback-test.xml in the classpath.

2. If no such file is found, logback tries to find a file called logback.groovy in the classpath.

3. If no such file is found, it checks for the file logback.xml in the classpath..

4. If no such file is found, service-provider loading facility (introduced in JDK 1.6) is used to resolve the implementation of com.qos.logback.classic.spi.Configurator interface by looking up the file META-INF\services\ch.qos.logback.classic.spi.Configurator in the class path. Its contents should specify the fully qualified class name of the desired Configurator implementation.

5. If none of the above succeeds, logback configures itself automatically using the BasicConfigurator which will cause logging output to be directed to the console.

 

Setting debug="true" within the element will output status information, assuming that:

1. the configuration file is found
2. the configuration file is well-formed XML.

If any of these two conditions is not fulfilled, Joran cannot interpret the debug attribute since the configuration file cannot be read. If the configuration file is found but is malformed, then logback will detect the error condition and automatically print its internal status on the console. However, if the configuration file cannot be found, logback will not automatically print its status data, since this is not necessarily an error condition. Programmatically invoking StatusPrinter.print() as shown in the MyApp2 application above ensures that status information is printed in every case.

 

the logback.xml configuration:

   /logdocument.log

   

     

     /logdocument.log.%d{yyyy-MM-dd}.log

 

     

     30

   

%date %level [%thread] %logger{10} [%file:%line] %msg%n

 

%date %level [%thread] %logger{10} [%file:%line] %msg%n