To use logback-access with Tomcat, after downloading the
logback distribution, place the files
- logback-core-0.9.30.jar and
- logback-access-0.9.30.jar under
+ logback-core-1.0.0.jar and
+ logback-access-1.0.0.jar under
$TOMCAT_HOME/lib/ directory, where $TOMCAT_HOME is the folder
- where you have installed Tomcat. We have tested logback-access
- with Tomcat version 6.0.20.
+ where you have installed Tomcat. This version of logback-access
+ has been tested with Tomcat version 7.0.21. It will not work with
+ Tomcat 6.x. However, the target platform for logback-access
+ version 0.9.30 is Tomcat 6.x.
In a configuration file, at the point where an appender is
+ referenced by name, it must be defined earlier in the configuration
+ file. Referencing an appender defined later in the file is not
+ allowed. Below are examples of correct and incorrect order of
+ definition and referece.
+
+
+
+
Below is an example of a correct ordering, where appender
+ definition precedes references made to it.
+
+
+
CORRECT ORDER
+
<configuration>
+ <!-- definition of appender STDOUT -->
+ <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
+ <encoder>
+ <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
+ </encoder>
+ </appender>
+
+ <root level="DEBUG">
+ <!-- appender referenced after it is defined -->
+ <appender-ref ref="STDOUT"/>
+ </root>
+</configuration>
+
+
Below is an example of an incorrect ordering, where appender
+ definition follows references made to it.
+
+
+
INCORRECT ORDER
+
<configuration>
+ <root level="DEBUG">
+ <!-- appender INCORRECTLY referenced before it is defined -->
+ <appender-ref ref="STDOUT"/>
+ </root>
+
+ <!-- definition of appender STDOUT -->
+ <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
+ <encoder>
+ <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
+ </encoder>
+ </appender>
+</configuration>
+
Logback jar files must be present on Jetty's class
path. These files are
- logback-core-0.9.30.jar and
- logback-classic-0.9.30.jar. These files
+ logback-core-1.0.0.jar and
+ logback-classic-1.0.0.jar. These files
should be placed under the $JETTY_HOME/lib
directory.
@@ -322,7 +322,7 @@
Since Jetty uses an older version of SLF4J internally,
we recommend that the old version be replaced by
- slf4j-api-1.6.2.jar. This file can be
+ slf4j-api-1.6.4.jar. This file can be
downloaded from the SLF4J project.
The logback-audit project is
designed for processing logging events having long-term business
- significance. Logback-audit is commercial software based on
- logback-core.
+ significance. Logback-audit is based on logback-core.
Please do your best to ensure that you are not sending HTML or
- "Styled" email to the list. If you are using Outlook or
- Outlook Express or Eudora, chances are that you are sending HTML
- email by default. There is usually a setting that will allow you
- to send "Plain Text" email.
-
-
-
Name
diff -Nru logback-0.9.30/docs/manual/appenders.html logback-1.0.0/docs/manual/appenders.html
--- logback-0.9.30/docs/manual/appenders.html 2011-09-20 22:18:25.000000000 +0000
+++ logback-1.0.0/docs/manual/appenders.html 2011-11-01 17:16:12.000000000 +0000
@@ -1696,9 +1696,10 @@
href="../xref/ch/qos/logback/classic/net/SMTPAppender.html">SMTPAppender
accumulates logging events in one or more fixed-size buffers and
sends the contents of the appropriate buffer in an email after a
- user-specified event occurs. By default, the email transmission is
- triggered by a logging event of level ERROR or higher. Moreover, by
- default, a single buffer is used for all events.
+ user-specified event occurs. SMTP email transmission (sending) is
+ performed asynchronously. By default, the email transmission is
+ triggered by a logging event of level ERROR. Moreover, by default,
+ a single buffer is used for all events.
The various properties for SMTPAppender are
@@ -1775,10 +1776,9 @@
By default, this option is set to "%logger{20} - %m".
In case the hostname of the SMTP client is not properly
+ configured, e.g. if the client hostname is not fully
+ qualified, certain SMTP servers may reject the HELO/EHLO
+ commands sent by the client. To overcome this issue, you may
+ set the value of the localhost
+ property to the fully qualified name of the client host. See
+ also the "mail.smtp.localhost" property in the documentation
+ for the com.sun.mail.smtp
+ package.
Logback relies on a configuration library called Joran which is
- part of logback-core. Logback's default configuration mechanism
- invokes JoranConfigurator on the default configuration
- file it finds on the class path. If you wish to
- override logback's default configuration mechanism for whatever reason, you can do so
- by invoking JoranConfigurator directly. The next
+
Logback relies on a configuration library called Joran, part of
+ logback-core. Logback's default configuration mechanism invokes
+ JoranConfigurator on the default configuration file it
+ finds on the class path. If you wish to override logback's default
+ configuration mechanism for whatever reason, you can do so by
+ invoking JoranConfigurator directly. The next
application, MyApp3, invokes JoranConfigurator on a
configuration file passed as a parameter.
@@ -508,19 +508,19 @@
public static void main(String[] args) {
// assume SLF4J is bound to logback in the current environment
- LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
+ LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();try {
JoranConfigurator configurator = new JoranConfigurator();
- configurator.setContext(lc);
- // the context was probably already configured by default configuration
- // rules
- lc.reset();
+ configurator.setContext(context);
+ // Call context.reset() to clear any previous configuration, e.g. default
+ // configuration. For multi-step configuration, omit calling context.reset().
+ context.reset();
configurator.doConfigure(args[0]);
} catch (JoranException je) {
// StatusPrinter will handle this
}
- StatusPrinter.printInCaseOfErrorsOrWarnings(lc);
+ StatusPrinter.printInCaseOfErrorsOrWarnings(context);
logger.info("Entering application.");
@@ -536,8 +536,8 @@
context, and then finally asks the configurator to configure the
context using the configuration file passed as a parameter to the
application. Internal status data is printed in case of warnings or
- errors.
-
+ errors. Note that for multi-step configuration,
+ context.reset() invocation should be omitted.
In principle, variable substitution can occur at any point where
- a value can be specified. The syntax of variable substitution is
- similar to that of Unix shells. The string between an opening
- ${ and closing } is interpreted as a key. The
- value of the substituted variable can be defined in the
- configuration file itself, in an external properties file or as a
- system property. The corresponding value replaces ${aKey}
- sequence. For example, if the java.home.dir system property is
- set to /home/xyz, then every occurrence of the sequence
- ${java.home.dir} will be interpreted as /home/xyz.
- As they often come in handy, the ${HOSTNAME} and ${CONTEXT_NAME}
- variables are automatically defined.
Note that the values defined via <property>
- element are actually inserted into the logger context. In other
- words, they become properties of the logger context. Consequently,
- they will be available in all logging events, including those sent
- to remote hosts via serialization.
+
As in many scripting languages, logback configuration files support
+ definition and substitution of properties. Properties can be defined
+ within the configuration file itself, in an external file, in an
+ external resource or even computed and defined on the fly.
+
+
+
Property substitution can occur at any point where a value can be
+ specified. The syntax of property substitution is similar to that of
+ Unix shells. The string between an opening ${ and closing
+ } is interpreted as a reference to the value of
+ the property. For property aKey, the string "${aKey}" will
+ be replaced the value held by the aKey property.
+
+
+
A property can be defined in local scope (the default),
+ in context scope, or in system scope. Local scope
+ is the default. A property with local scope exists from the point
+ of its definition until the end of configuration. A property with
+ context scope is inserted into the context and lasts as long as the
+ context or until it is cleared. Once defined, a property in
+ context scope is part of the context. As such, it is available in
+ all logging events, including those sent to remote hosts via
+ serialization. A property with system scope is inserted into the
+ JVM's system properties and lasts as long as the JVM or until it is
+ cleared.
+
+
+
As they often come in handy, the HOSTNAME and CONTEXT_NAME
+ properties are automatically defined and have context scope.
+
+
Properties are looked up in the the local
+ scope first, in the context scope second, in the system properties
+ scope third, and in the OS environment last.
+
+
+
During substitution, properties are looked up in the local scope
+ first, in the context scope second, in the system properties scope
+ third, and in the OS
+ environment fourth and last.
+
Properties can be defined one at a time in the configuration file
+ itself or loaded wholesale from an external properties file or an
+ external resource.
The next example shows a variable, a.k.a. a substitution
property, declared at the beginning of the configuration file. It is
@@ -1299,8 +1328,7 @@
(logback-examples/src/main/java/chapters/configuration/variableSubstitution1.xml)
The next example shows the use of a System property to achieve
the same result. The property is not declared in the configuration
file, thus logback will look for it in the System properties. Java
@@ -1354,8 +1381,8 @@
separate file
(logback-examples/src/main/java/chapters/configuration/variableSubstitution3.xml)
The scope attribute of the
+ <property> element can be used to set the scope of
+ properties. The scope attribute admit the
+ "local", "context" and "system" strings as possible values.
+
In the above example, given that the nodeId property is
+ defined in the context scope, it will be available in every logging
+ event, even those sent to remote hosts via serialization.
+
Nested variable substitution
Nested variable substitution is also supported. By nested, we
@@ -1550,24 +1612,22 @@
</else>
</if>
-
The condition is a Java expression in which only context properties
- or system properties are accessible. For a key passed as argument,
- the property() or its shorter equivalent
+
The condition is a Java expression in which only context
+ properties or system properties are accessible. For a key passed as
+ argument, the property() or its shorter equivalent
p() methods return the String value of the property.
- For example, to access the value of a property with key "k", you would
- write property("k") or equivalently
+ For example, to access the value of a property with key "k", you
+ would write property("k") or equivalently
p("k"). If the property with key "k" is undefined, the
property method will return the empty string and not null. This
- avoids the need to check for null values. If you need to check
- whether a property is null, the isNull() method is
- provided. For example, you can write isNull("k").
-
-
In the next example, the ConsoleAppender will be
- attached to the root logger, but only if the HOSTNAME is
- "torino". Note that the FileAppender named "FILE" is
- attached to the root logger in any case.
-
+ avoids the need to check for null values.
+
The isDefined() method can be used to check whether
+ a property is defined. For example, to check whether the property
+ "k" is defined you would write isDefined("k")
+ Similarly, if you need to check whether a property is null, the
+ isNull() method is provided. Example:
+ isNull("k").
- If you wish to print chapters in this document, we recommend
- that you do so using Firefox 2+, with Adapt to
- page size enabled, or Opera.
-
-
The complete logback manual documents the latest version of
logback framework. In over 150 pages and dozens of concrete
diff -Nru logback-0.9.30/docs/manual/introduction.html logback-1.0.0/docs/manual/introduction.html
--- logback-0.9.30/docs/manual/introduction.html 2011-09-20 22:18:25.000000000 +0000
+++ logback-1.0.0/docs/manual/introduction.html 2011-11-01 17:16:12.000000000 +0000
@@ -72,7 +72,7 @@
The logback-*.jar files are part of the logback
- distribution whereas slf4j-api-1.6.2.jar ships
+ distribution whereas slf4j-api-1.6.4.jar ships
with SLF4J, a separate project.
@@ -240,15 +240,15 @@
As its build tool, logback relies on Maven2, a widely-used open-source
+ href="http://maven.apache.org">Maven, a widely-used open-source
build tool.
-
Once you have installed Maven2, building the logback project,
+
Once you have installed Maven, building the logback project,
including all its modules, should be as easy as issuing a mvn
- package command from within the directory where you
+ install command from within the directory where you
unarchived the logback distribution. Maven will automatically
- download the required external libraries.
+ download the required external libraries.
Logback distributions contain complete source code such that you
@@ -257,42 +257,10 @@
adhere to the conditions of the LGPL license or the EPL license.
-
Logback has been built and tested with the following JDKs.
+
diff -Nru logback-0.9.30/docs/manual/layouts.html logback-1.0.0/docs/manual/layouts.html
--- logback-0.9.30/docs/manual/layouts.html 2011-09-20 22:18:25.000000000 +0000
+++ logback-1.0.0/docs/manual/layouts.html 2011-11-01 17:16:12.000000000 +0000
@@ -1057,6 +1057,11 @@
information. In short, %rootException is very similar to
%xException, only the order of exception output is reversed.
+
+
First, place the logback jars (that is
- logback-classic-0.9.30.jar,
- logback-core-0.9.30.jar and
- slf4j-api-1.6.2.jar) in Tomcat's global (shared) class
+ logback-classic-1.0.0.jar,
+ logback-core-1.0.0.jar and
+ slf4j-api-1.6.4.jar) in Tomcat's global (shared) class
folder. In Tomcat 6.x, this directory is
$TOMCAT_HOME/lib/.
The logback-access module now targets Tomcat 7.x and Jetty 7.x
+ & 8.x as its servlet container platforms. This fixes LBACCESS-17
+ reported by Grzegorz Grzybek.
+
+
+
+
Breaking change: properties are no longer automatically
+ inserted into the context
+
+
Properties now have a scope. Previously, the definition of a
+ property added it to the context. As of version 1.0, properties
+ are local, i.e. transient by default. For further details, please
+ refer to the documentation
+ on properties.
+
+
+
Environment variables are now look up during property
+ substitution. This feature was requested in LBCORE-212 by
+ Alexandre Garnier.
+
+
+
SMTPAppender now sends emails asynchronously.
+
+
Investigation of LBCORE-224
+ reported by Cesar Alvarez Nunez points to bug in the JVM rather
+ than in logback. A workaround has been found by using
+ CopyOnWriteArrayList instead of the apparently buggy
+ ReadWriteLock.
+
+
In STARTTLS mode, "mail.smtp.auth" property is no longer set
+ automatically. This fixes LBCORE-225
+ reported by Mark Woon.
+
Logback-access now supports conditional configuration. This
+ fixes LBACCESS-27
+ reported by Marshall Pierce.
+
+
Logback-access now supports inclusion of configuration
+ files. See the chapter about
+ configuration in the logback's online manual for more
+ information.
+
+
Added ch.qos.logback.core.read to "Import-Package"
+ declaration in logback-classic's manifest file. This fixes LBCLASSIC-131
+ reported by Michal Prihoda and Thomas Jaeckle.
+
+
Fixed infinitely recursive calls in
+ AccessConverter#addError methods as reported in LBACCESS-25 by
+ Pierre Queinnec.
+
+
+
Fixed incorrect switch fallthrough while selecting between the
+ H2 and HSQL dialects as reported in LBCORE-218 by
+ Pierre Queinnec.
+
+
+
+
+
September 21st, 2011 - Release of version 0.9.30
Archive removal can now deal with prolonged periods of
application inactivity and application stop and restarts. The
@@ -1444,7 +1513,7 @@
logback's configuration framework. A file can contain an
include element that has a file or url
attribute pointing to a configuration file. See the chapter about
+ href="manual/configuration.html#fileInclusion">chapter about
configuration in the logback's online manual for more
information.
The logback-*.jar files are part of the logback
- distribution whereas slf4j-api-1.6.2.jar ships
+ distribution whereas slf4j-api-1.6.4.jar ships
with SLF4J, a separate project.
@@ -49,8 +49,8 @@
chapters.introduction.HelloWord1 with the following command:
-
You can import the logback project into Eclipse. Since logback
- uses maven as its build system, the "maven eclipse:eclipse" command
- will create the .classpath and .project files for
- Eclipse. You can then import the logback project into Eclipse in one
- or two clicks.
+
If you wish to contribute to hack to the project or just hack it
+ for your own needs, you will probably want to import logback as a
+ project into your favorite IDE. Logback uses Maven as its build
+ tool. The Scala language is used in certain logback test
+ cases. Moreover, logback offers a Groovy-based configurator so
+ there is a dependency on the Groovy language as well. It follows
+ that your IDE should have plugins for Maven, Scala and Groovy in
+ order to build logback from your within IDE. The
+ Scala+Groovy dependecy just mentioned are build-time
+ dependencies. The only mandatory logback dependency at runrime is
+ the JRE, unless of course you wish to use the Groovy configurator
+ in which case Groovy runtime will be a required dependency as
+ well. Also note that building from the command line is fairly
+ trivial, the command 'mvn install' given from $LOGBACK_HOME folder
+ should suffice.
+
+
Building logback with IntelliJ IDEA
+
+
Assuming you have the latest version of IntelliJ IDEA installed,
+ the only required additional plugin is the Scala plugin. IntelliJ
+ IDEA supports Maven as well as Groovy out of the box. Once you have
+ the Scala plugin installed, you can import logback into
+ IDEA. Select File→ New Project → Import from external
+ model→ Maven, then select $LOGBACK_HOME as the Root
+ directory. The import should finish successfully in a few
+ seconds. If you import logback before the scala-plugin is
+ installed, you would need to re-import logback as a project after
+ the Scala plugin is installed.
+
+
Building with Eclipse
+
+
Building logback under Eclipse is a little trickier. Here are
+ instructions for building logback under Eclipse in 61 easy steps.
+
+
+
The author does not wish to unduly disparage
+ m2eclipse. However, as of this writing that is October
+ 2011, it appears that the key to building logback under Eclipse is
+ to avoid using m2eclipse. If you have
+ m2eclipse installed, you can disable it by removing
+ the Maven Nature for a given project. And without further ado here
+ are the steps:
+
+
+
+
+
Install Eclipse Indigo, aka Eclipse 3.7
+
in eclipse.ini file modify the parameter "mx",
+ i.e. change -Xmx384m to -Xmx1384m
+
+
In Eclipse, select Help → Intall new Software →
+ Work with http://dist.springsource.org/release/GRECLIPSE/e3.7/
+ and then Select "Groovy-Eclipse Feature". Installation of other
+ plugins in particular "m2e Configurator for Groovy-Eclipse" is
+ not necessary
+
+
Similar to the previous step, install Scala IDE for Eclipse
+ plugin from http://download.scala-ide.org/releases-29/2.0.0-beta. Installation
+ of "JDT Weaving" or "Scala IDE for Eclipse Source feature" are
+ not necessary.
+
+
cd $LOGBACK_HOME
+
+ where $LOGBACK_HOME stands for the location where you cloned the
+ logback project from github
+
+
In case they exist, remove .settings,
+ .classpath, .project folders (again if any)
+ under $LOGBACK_HOME and its sub-folders. Somehow, this step seems
+ to be crucial.
+
+
From the command line, run mvn eclipse:eclipse
+ in $LOGBACK_HOME
+
+
In Eclipse, import the logback project: Import→
+ General→ Existing Prokects into Workspace, select
+ $LOGBACK_HOME folder for the import
+
+
+
+
In Eclipse, add the scala nature to logback-core project:
+ (right click on logback-core project→ Configure→ Add
+ Scala Nature)
+
+
+
In Eclipse, remove the
+ logback-classic/target/generated-sources/groovy-sttubs/main
+ directory from the list of source folders (logback-classic→
+ project properties → Java Build Path)
+
+
+
In Eclipse, clean all projects in Eclipse (Project →
+ Clean)
+
+
+
In Eclipse, select logback-classic project and convert it to
+ "Groovy project" (right click on logback-classic project →
+ Configure → Convert Groovy to Project)
+
')
document.write('We are actively looking for volunteers to proofread the documentation. Please send your corrections or suggestions for improvement to "corrections' + AAT +'qos'+DOOTT+'ch". See also the instructions for contributors.');
document.write('
-
-
-
-
-
-
-
-
-
- 
');
document.write('
');
-document.write('