![]() |
Copyright © 2005-2006, QOS.ch This work is licensed under a Creative Commons Attribution 2.5 License. |
Logback was designed as a modular framework from the start. Being able to use logback's internal core in many situations, without heavy coding or complex specific configuration was one of our goals.
Lobgack access integrates with Servlet containers such as Jetty and Tomcat to provide HTTP-access log functionality.
Integrating logback into Jetty is rather simple. Once done, you can benefit from the power and flexibility found only in fully-fledged logging systems.
To use logback-access with Jetty, after downlading the logback distribution, place the files logback-core-VERSION.jar and logback-access-VERSION.jar under $JETTY_HOME/lib directory, where $JETTY_HOME is the folder where you have installed Jetty. We tested logback-access module with Jetty version 6.0.1.
The ch.qos.logback.access.jetty.RequestLogImpl
class implements jetty's RequestLog
interface. This interface is used by Jetty to allow external
components to manage request logging.
In logback, logging destinations are called Appenders. These classes
can be attached directly to RequestLogImpl
.
To configure jetty in order to use logback's
RequestLogImpl
, add the following lines
to the jetty configuration file, namely $JETTY_HOME/etc/jetty.xml:
<Ref id="requestLog"> <Set name="requestLog"> <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"> </New> </Set> </Ref>
These lines reference the requestLog functionnality of Jetty, setting the actual class that will be called at each logging request.
By default, RequestLogImpl
looks for a logback
configuration file called logback-access.xml, in the
same folder where jetty.xml is located. This
configuration file contains directives for configuring logback
components. Among others, you can specify the appenders where
the logging requests will be sent, and their format.
Altough similar, the logback-access.xml file is slightly different than the usual logback classic configuration file. Appenders and Layouts are declared the exact same way. However, in the access module there is no notion of loggers and consequently loggers elements are disallowed in configuraiton files for logback-access.
As long the path is specified, you can place the logback configuration file in other location. Here is another example of jetty configuration file, with a path to the logback access configuration file.
<Ref id="requestLog"> <Set name="requestLog"> <New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"> </New> <Set name="fileName">path/to/myaccess.xml</Set> </Set> </Ref>
Here is a sample logback-access.xml file that you can immediately put to use:
<configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.access.PatternLayout"> <Pattern>%h %l %u %user %date "%r" %s %b</Pattern> </layout> </appender> <appender-ref ref="STDOUT" /> </configuration>
It declares a ConsoleAppender
which directs its
output at the console. The ConsoleAppender
contains
a PatternLayout
format the output. The log format is
specied using the %h %l %u %user %date "%r" %s %b" pattern which
is the Commong Log Format (CLF). This format is recognized by log
analysers such as Analog or AWStats.
Instead of specifying the complete pattern, the word "common" or "clf" can be used as a shorthand. Thus, the following are all equivalent
<Pattern>%h %l %u %user %date "%r" %s %b</Pattern> <Pattern>common</Pattern> <Pattern>clf</Pattern>
The so called "combined" format is also widely recognized. It is defined as the '%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"' pattern. As a facilitator, you can use the "combined" as a shorthand. Thus, the following directive
<layout class="ch.qos.logback.access.PatternLayout"> <Pattern>%h %l %u %t "%r" %s %b "%i{Referer}" "%i{User-Agent}"</Pattern> </layout>
is equivalent to:
<layout class="ch.qos.logback.access.PatternLayout"> <Pattern>combined</Pattern> </layout>
Another configuration file, using logback'
RollingFileAppender
, could be:
<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <ActiveFileName>access.log"</ActiveFileName> <FileNamePattern>access.%d{yyyy-MM-dd}.log.zip</FileNamePattern> </rollingPolicy> <layout class="ch.qos.logback.access.PatternLayout"> <Pattern">combined</Pattern"> </layout> </appender> <appender-ref ref="FILE" /> </configuration>
Here, there is no output to the console. Instead, logback access logs to the file named access.log. This file will be rolled over every 24 hours. We specify in the configuration the name of the file where the actual logging is added, and the pattern that the archived files must match. The newly archived file will be automatically compressed.
These two configuration examples should give you an idea of the possibilities offered by the logback-access module. In principle, most of the things that you can do with logback-classic module are equally possible with logback-access.
An http-specific implementation of PatternLayout
is
included in the access module. The
ch.qos.logback.access.PatternLayout
provides a
way to format the logging output that is just as easy and
flexible as the PatternLayout
found in logback
classic.
Logback access PatternLayout
offers the following
possibilities:
Conversion Character or Word | Effect |
---|---|
a / remoteIP |
Remote IP address. |
A / localIP |
Local IP address. |
b / B / byteSent |
Response's content length. |
h / clientHost |
Remote host. |
H / protocol |
Request protocol. |
l |
Remote log name. In logback-access, this converter always returns the value "-". |
reqParameter{paramName} |
Parameter of the response. This conversion word can be followed by a key whose corresponding data will be extracted from the header information. |
i{header} / header{header} |
Request header. Just like the reqParameter conversion word, reqParameter can be followed by a key. |
m / requestMethod |
Request method. |
r / requestURL |
URL requested. |
s / statusCode |
Status code of the request. |
t / date |
Date of the event. |
u / user |
Remote user. |
U / requestURI |
Requested URI. |
v / server |
Server name. |
localPort |
Local port. |
reqAttribute{attributeName} |
Attribute of the request. Just like the reqParameter conversion word, reqAttribute can be followed by a key. |
reqCookie{cookie} |
Request cookie. Just like the reqParameter conversion word, reqCookie can be followed by a key. |
responseHeader{header} |
Header of the response. Just like the reqParameter conversion word, responseHeader can be followed by a key. |