## Frequently Asked Questions

### Logback project

1. Why is logback distributed under LGPL and not the Apache Software License?
2. What are logback's dependencies, i.e. JDK version and third-party libraries?

### Logback Classic

1. Are logback loggers serializable?
2. How does the automatic configuration work?
3. Where should the configuration files, logback-test.xml or logback.xml, be located on the classpath?
4. Is it possible for multiple JEE applications to share the same configuration file but without stepping on each other's toes?
5. How can I disable logging from the command line?
6. How can Jetty be instructed to use logback-classic as its logging implementataion?

## Logback project

Why is logback distributed under LGPL and not the Apache Software License?

  The logback project is distributed under the LGPL license in order to emphasize the fact that it is a related but different project than log4j.

  Given that Java v7 will be distributed under GPL, we expect GPL and LGPL to become even more prevalent in the Java world.

  In short, LGPL is a reasonable and widely-accepted license. Let well alone.

What are logback's dependencies, i.e. JDK version and third-party libraries?

  This question is answered on a separate page dedicated to the question of dependencies.

## Logback-classic

How does the automatic configuration work?

  This question is answered in the relevant section of the logback manual.

Where should the configuration files, logback-test.xml or logback.xml, be located on the classpath?

  Configuration files such as logback-test.xml or logback.xml can be located directly under any folder declared in the class path. For example, if the class path reads "c:/java/jdk15/lib/rt.jar;c:/mylibs/" then the logback.xml file should be located directly under "c:/mylibs/", that is as "c:/mylibs/logback.xml". Placing it under a sub-folder of c:/mylibs/, say, c:/mylibs/other/, will not work.

  For web-applications, configuration files can be placed directly under WEB-INF/classes/.

Are logback loggers serializable?

  Yes. A logback logger is an SLF4J logger and SLF4J loggers are serializable. This means that an object referencing a logger will be alble to log after its deserialization.

  The deserialized logger instance will be generated by `org.slf4j.LoggerFactory`. Thus, it is possible for a logback logger to be deserialized as a log4j or j.u.l. logger, depending on the deserialization environment.

Is it possible for multiple JEE applications to share the same configuration file but without stepping on each other's toes?

  Yes, it is. Using variable substitution, it is possible to have a single configuration file to output logs to different destinations depending on each JEE application. Here is a sample configuration file designed for this purpose.

  <configuration> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <!-- "application-name" is a variable --> <File>c:/logs/${application-name}.log</File> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d %p %t %c - %m%n</Pattern> </layout> </appender> <root level="debug"> <appender-ref ref="FILE"/> </root> </configuration>

  Assuming each JEE application loads a different copy of logback classes into memory, if we can somehow inject a different value for `application-name` each time an application starts, logs will be output to different files. We just need to initialize logback with the above configuration file while injecting a different value for `application-name` variable. Here is sample code that programmatically configures logback. It should be invoked during the initialization of your JEE applications.

  LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory(); // inject the name of the current application as "applicaiton-name" // property of the LoggerContext context.putProperty("application-name", NAME_OF_CURRENT_APPLICATION); JoranConfigurator jc = new JoranConfigurator(); jc.setContext(context); context.reset(); // override default configuration jc.doConfigure("/path/to/the/above/configuration/file.xml");

How can I disable logging from the command line?

  Logback does not allow disabling logging from the command line. However, if the configuration file allows it, you can set the level of logers on the command line via a java system property. Here is such a configuration file.

  <configuration> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %level %logger - %m%n</Pattern> </layout> </appender> <root level="${root-level:-INFO}"> <appender-ref ref="CONSOLE"/> </root> </configuration>

  Making use of variable substitution as well as default values for variables, if the root-level system property is set to `OFF`, then all logging will be turned off. However, if it is not set, it will assume the default value of `INFO`. Note that you can set the root-level system property to any level value of your choice. The value `OFF` is just an example.

How can Jetty be instructed to use logback-classic as its logging implementataion?

  The Jetty application server uses SLF4J for its internal logging.

  Logback jar files must be present on Jetty's class path. These files are logback-core-${project.version}.jar and logback-classic-${project.version}.jar. These files should be placed under the $JETTY_HOME/lib directory.

  Since Jetty's uses an older version of SLF4J internally, we recommend that the old version be replaced by slf4j-api-${slf4j.version}.jar. This file can be downloaded from the SLF4J project.

  For automaticly configuring logback-classic, you can place the file logback.xml under the $JETTY_HOME/resources directory. You can find sample configuration files in the logback-examples/src/main/java/chapters/appenders/conf/ folder shipping within the logback distribution.