File: access.html

package info (click to toggle)
logback 1%3A1.2.3-5
links: PTS, VCS
area: main
in suites: buster
size: 18,876 kB
sloc: java: 56,764; xml: 3,403; sql: 552; sh: 141; makefile: 2
file content (618 lines) | stat: -rw-r--r-- 25,095 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
    <title>Logback-access</title>
    <link rel="stylesheet" type="text/css" href="css/common.css" />
    <link rel="stylesheet" type="text/css" href="css/screen.css" media="screen" />
    <link rel="stylesheet" type="text/css" href="css/_print.css" media="print" />
    <link rel="stylesheet" type="text/css" href="css/prettify.css" media="screen" />
  </head>
  <body onload="prettyPrint()">
    <script type="text/javascript">prefix='';</script>
    <script type="text/javascript" src="js/prettify.js"></script>    
    <script src="templates/header.js" type="text/javascript"></script>
    <div id="left">
      <script src="templates/left.js" type="text/javascript"></script>
    </div>
    <div id="right">
      <script src="templates/right.js" type="text/javascript"></script>
    </div>

    <div id="content">  

    <h2>HTTP-access logs with logback-access, Jetty and Tomcat</h2>

    <div class="author">
      Authors: Ceki G&#252;lc&#252;, S&#233;bastien Pennec
    </div>


    <script src="../templates/creative.js" type="text/javascript"></script>

    <h1>Introduction</h1>

    <p>The logback-access module, part of the standard logback
    distribution, integrates with Servlet containers such as Jetty or
    Tomcat to provide rich and powerful HTTP-access log functionality.
    </p>

    <p>Logback was designed as a modular framework from the
    start. Making logback-core reusable under different circumstances
    without much recoding was one of our main goals. In accordance
    with this strategy, logback-access builds on top of logback-core
    and can thus provide much of the functionality of logback-classic
    but in the scope of HTTP-access logging. </p>

    <p>It should be noted that while logback-access requires
    logback-core, it is independent of logback-classic as well as
    slf4j. Just as importantly, logback-access artifact must be
    installed at the container level, not at web-application level. It
    does not make sense to bundle <em>logback-access.jar</em> at the
    level of a web-application.
    </p>

    <h1><a name="tomcat" href="#tomcat">Logback-access under Tomcat</a></h1>



   

    <p>To use logback-access with Tomcat, after downloading the
    logback distribution, place the files
    <em>logback-core-1.2.3.jar</em> and
    <em>logback-access-1.2.3.jar</em> under
    $TOMCAT_HOME/lib/ directory, where $TOMCAT_HOME is the folder
    where you have installed Tomcat.
    </p>

    <p class="highlight">Deploying recent versions of logback-access
    on Tomcat 6.x (instead of Tomcat 7.x) is likely to cause the
    server to crash.</p>

    <p><span class="label notice">Tomcat 7.x</span> This version of
    logback-access has been tested with Tomcat version 7.0.62. It will
    not work with Tomcat 6.x.
    </p>
   
    <p><span class="label notice">Tomcat 6.x</span> Logback-access
    version 0.9.30 will deploy on Tomcat 6.x.</p>

    <h2>LogbackValve</h2>

    <p>The <a
    href="xref/ch/qos/logback/access/tomcat/LogbackValve.html">
    <code>ch.qos.logback.access.tomcat.LogbackValve</code></a> class
    extends Tomcat's <code><a
    href="http://tomcat.apache.org/tomcat-5.5-doc/catalina/docs/api/org/apache/catalina/valves/ValveBase.html">
    ValveBase</a></code> class. Valves are usually associated together
    to form a processing pipeline.
    </p>

    <p>To configure Tomcat in order to use <code>LogbackValve</code>,
    add the following lines to the tomcat server configuration file,
    namely <em>$TOMCAT_HOME/conf/server.xml</em>:
    </p>
    <pre class="source">&lt;Valve className="ch.qos.logback.access.tomcat.LogbackValve"/></pre>

    <p>This line is usually nested within an <code>&lt;Engine></code>
    or <code>&lt;Host></code> element.
    </p>

    <p>By default, <code>LogbackValve</code> looks for a configuration
    file called <em>logback-access.xml</em>, in the same folder where
    <em>server.xml</em> is located, that is in
    <em>$TOMCAT_HOME/conf/</em>. This configuration file contains
    directives for configuring logback-access components. It is used
    to specify appenders where the logging requests will be
    sent. Please refer to the <a href="#configuration">logback-access
    configuration section</a> further below.
    </p>

    <p>If the <code>LogbackValve</code> is not able to read a configuration file
    from the filesystem, it will attempt to load it as a resource (i.e.
    getClassLoader().getResourceAsStream()). This might be helpful in scenarios
    where your application is embedding Tomcat (e.g. using Spring Boot.) As
    mentioned above, if no filename is set, it defaults to looking for a
    resource named logback-access.xml.
    </p>

    <p>In order to help with troubleshooting, by default, the
    <code>LogbackValve</code> will print its internal status at its
    initialization. Typical output would look as:
    </p>
    
    <p class="source">21:56:09,921 |-INFO in c.q.lb.access.j.a.ConfigurationAction - Ignoring debug attribute.
21:56:09,921 |-INFO in c.q.lb.core.j.a.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
21:56:09,921 |-INFO in c.q.lb.core.j.a.AppenderAction - Naming appender as [STDOUT]
21:56:10,015 |-INFO in c.q.lb.core.j.a.AppenderAction - Popping appender named [STDOUT] from the object stack
21:56:10,015 |-INFO in c.q.lb.core.j.a.AppenderRefAction - Attaching appender named [STDOUT] to ch.qos.logback.access.tomcat.LogbackValve[Catalina]
21:56:10,015 |-INFO in c.q.lb.access.j.a.ConfigurationAction - End of configuration.</p>

    <p>It is possible to override default status printing by specifying
    the "quiet" attribute in the <code>Valve</code>
    element. Similarly, it is also possible to set the filename for
    the logback-access configuration file. Here is an example.
    </p>

   <pre class="prettyprint source">&lt;Valve className="ch.qos.logback.access.tomcat.LogbackValve"
       quiet="true" filename="c:/my-logback-access.xml"/></pre>

    <h3><a name="viewingStatusMessages"
    href="#viewingStatusMessages">Viewing status messages</a></h3>

    <p>Logback-access ships with a servlet called
    <code>ViewStatusMessagesServlet</code>. This servlet prints the
    internal status messages of the <code>LogbackValve</code> as an
    HTML table. Here is sample output.
    </p>


    <a href="images/lbAccessStatus.jpg">
     <img src="images/lbAccessStatus.jpg" alt="click to enlarge" width="90%"/>
    </a>

    <p>To add this servlet to your web-application, add the following
    lines to its <em>WEB-INF/web.xml</em> file.</p>

    <pre class="prettyprint source">  &lt;servlet>
    &lt;servlet-name>AccessViewStatusMessages&lt;/servlet-name>
    &lt;servlet-class>ch.qos.logback.access.ViewStatusMessagesServlet&lt;/servlet-class>
  &lt;/servlet>

  &lt;servlet-mapping>
    &lt;servlet-name>AccessViewStatusMessages&lt;/servlet-name>
    &lt;url-pattern>/lbAccessStatus&lt;/url-pattern>
  &lt;/servlet-mapping></pre>
   
    <p>The <code>ViewStatusMessages</code> servlet will available
    under the URL <code>http://host/yourWebapp/lbAccessStatus</code>
    </p>
    
    
    <h1><a name="jetty" href="#jetty">Logback-access under
    Jetty</a></h1>

    <p>After downloading the logback distribution, place the files
    <em>logback-core-VERSION.jar</em> and
    <em>logback-access-VERSION.jar</em> under $JETTY_HOME/lib
    directory, where $JETTY_HOME is the folder where you have
    installed Jetty. Versions of logback-access 0.9.31 and later
    target Jetty versions 7.x and 8.x. Logback-access versions 0.9.30
    and earlier target Jetty version 6.x.
    </p>

    <h3>Logback's implementation of
    <code>org.eclipse.jetty.server.RequestLog</code> interface</h3>

    <p>The <a
    href="xref/ch/qos/logback/access/jetty/RequestLogImpl.html">
    <code>ch.qos.logback.access.jetty.RequestLogImpl</code></a> class
    implements Jetty's <code><a
    href="http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/server/RequestLog.html">RequestLog</a></code>
    interface. Jetty delegates the management of access logging
    functionality to implementations of this interface.
    </p>

    <p>In logback, a logging destination is called an "appender" which
    can be directly attached to a
    <code>ch.qos.logback.access.jetty.RequestLogImpl</code> instance.
    </p>


    <p>In order to configure Jetty to use logback-access's
    <code>RequestLogImpl</code>, please add the following lines to
    Jetty's main configuration file, namely
    <em>$JETTY_HOME/etc/jetty.xml</em>:
    </p>
    <pre class="prettyprint source">&lt;Ref id="RequestLogHandler"&gt;
  &lt;Set name="requestLog"&gt;
    &lt;New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"&gt;
    &lt;/New&gt;
  &lt;/Set&gt;
&lt;/Ref&gt;</pre>

    <p>Please note that the above jetty configuration snippet makes
    reference to "RequestLogHandler". Check your jetty.xml
    configuration file and add a <code>RequestLogHandler</code> if it
    has not been already added. Here is a configuration snipped to set
    you on the right tract.</p>

    <pre class="prettyprint source">&lt;Set name="handler">
  &lt;New id="Handlers" class="org.eclipse.jetty.server.handler.HandlerCollection">
    &lt;Set name="handlers">
      &lt;Array type="org.eclipse.jetty.server.Handler">        
        &lt;Item>
          &lt;New id="Contexts" 
               class="org.eclipse.jetty.server.handler.ContextHandlerCollection"/>
        &lt;/Item>
        &lt;Item>
          &lt;New id="DefaultHandler" 
               class="org.eclipse.jetty.server.handler.DefaultHandler"/>
        &lt;/Item>
        <b>&lt;!-- add a RequestLogHandler --&gt;</b>
        <b>&lt;Item></b>
          <b>&lt;New id="RequestLogHandler"</b>
               <b>class="org.eclipse.jetty.server.handler.RequestLogHandler"/></b>
        <b>&lt;/Item></b>
      &lt;/Array>
    &lt;/Set>
  &lt;/New>
&lt;/Set></pre>


    <p>By default, <code>RequestLogImpl</code> looks
    for a logback configuration file called
    <em>logback-access.xml</em>, in the same folder where
    <em>jetty.xml</em> is located. This configuration file contains
    directives for configuring logback components such as appenders
    and layouts.
    </p>

    <p>As long the path is specified, you can place the logback
    configuration file in any location. Here is another example of a
    Jetty configuration file, including the path to the logback-access
    configuration file here named <em>myaccess.xml</em>.
    </p>

    <pre class="prettyprint source">&lt;Ref id="RequestLogHandler"&gt;
  &lt;Set name="requestLog"&gt;
    &lt;New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"&gt;
       &lt;Set name="fileName"&gt;path/to/myaccess.xml&lt;/Set&gt;
    &lt;/New&gt;   
  &lt;/Set&gt;
&lt;/Ref&gt;</pre>

   <p>For embedded Jetty, it is helpful to lookup for the
   logback-access configuration file as a class path resource. This
   can be accomplished by setting the <em>resource</em> property to
   the file name to look up on the class path.
   </p>

   <pre class="prettyprint source">&lt;Ref id="RequestLogHandler"&gt;
  &lt;Set name="requestLog"&gt;
    &lt;New id="requestLogImpl" class="ch.qos.logback.access.jetty.RequestLogImpl"&gt;
       &lt;Set name="<span class="bold">resource</span>"&gt;as/classpath/resource/myaccess.xml&lt;/Set&gt;
    &lt;/New&gt;   
  &lt;/Set&gt;
&lt;/Ref&gt;</pre>

  <h1><a name="configuration" href="#configuration">Logback-access
  configuration</a></h1>


  <p>Although similar, the format of <em>logback-access.xml</em>
  configuration file is slightly different than the configuration file
  format logback-classic.  Appenders and Layouts are declared the
  exact same way. However, in the access module there is no notion of
  loggers and consequently logger elements are disallowed.
  </p>


    <h3>Example 1: basic logback-access configuration</h3>
    <p>
      Here is a small but fully functional <em>logback-access.xml</em>
      configuration file:
    </p>
    <pre class="prettyprint source">&lt;configuration&gt;
  &lt;!-- always a good activate OnConsoleStatusListener -->
  &lt;statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />  

  &lt;appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"&gt;
    &lt;encoder&gt;
      &lt;pattern>%h %l %u %user %date "%r" %s %b&lt;/pattern&gt;
    &lt;/encoder&gt;
  &lt;/appender&gt;

  &lt;appender-ref ref="STDOUT" /&gt;
&lt;/configuration&gt;</pre>
    <p>
    It declares a <code>ConsoleAppender</code> which prints its output
    on the console.  The <code>ConsoleAppender</code> contains an
    <code>Encoder</code> object responsible for formatting output. The
    log format is specified by the "%h %l %u %user %date "%r" %s %b"
    pattern which incidentally corresponds to the Common Log Format
    (CLF). This format is recognized by log analyzers such as <a
    href="http://www.analog.cx/">Analog</a> or <a
    href="http://awstats.sourceforge.net/">AWStats</a>.
    </p>

    <p>The words "common" or "clf" are interpreted as shorthands for
    the said pattern. Thus, the following are all equivalent:
    </p>
    
    <pre class="prettyprint source">&lt;pattern>%h %l %u %user %date "%r" %s %b&lt;/pattern&gt;
&lt;pattern>common&lt;/pattern&gt;
&lt;pattern>clf&lt;/pattern&gt;</pre>

  <p>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
  </p>

  <pre class="prettyprint source">&lt;encoder&gt;
  &lt;pattern>%h %l %u [%t] "%r" %s %b "%i{Referer}" "%i{User-Agent}"&lt;/pattern&gt;
&lt;/encoder&gt;</pre>

  <p>is equivalent to:</p>

  <pre class="prettyprint source">&lt;encoder&gt;
  &lt;pattern>combined&lt;/pattern&gt;
&lt;/encoder&gt;</pre>


    <h3>Example 2: RollingFileAppender</h3>

    <p>The configuration file below configures a daily rolling
    <code>RollingFileAppender</code>. Note that due to the
    <em>.zip</em> suffix included in the value for <span
    class="option">fileNamePattern</span> option, the log files are not
    only rolled daily, but they are also automatically compressed.</p>


 <pre class="prettyprint source">&lt;configuration&gt;
  &lt;!-- always a good activate OnConsoleStatusListener -->
  &lt;statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />  

  &lt;appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"&gt;
    &lt;file&gt;access.log&lt;/file&gt;
    &lt;rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"&gt;
      &lt;fileNamePattern&gt;access.%d{yyyy-MM-dd}.log.zip&lt;/fileNamePattern&gt;
    &lt;/rollingPolicy&gt;

    &lt;encoder&gt;
      &lt;pattern&gt;combined&lt;/pattern&gt;
    &lt;/encoder&gt;
  &lt;/appender&gt;
 
  &lt;appender-ref ref="FILE" /&gt;
&lt;/configuration&gt;</pre>

    <p>These two examples should give you an idea of the possibilities
    offered by logback-access. In principle, most if not all of the
    features available in logback-classic are also available in
    logback-access.
    </p>

    <h3>PatternLayout</h3>

    <p>Logback-access ships with an http-specific implementation of <a
    href="xref/ch/qos/logback/access/PatternLayout.html">
    <code>PatternLayout</code></a>. For detailed instructions on how
    to use the <code>PatternLayout</code>, please refer to the <a
    href="manual/layouts.html#AccessPatternLayout">corresponding
    chapter</a> of the logback manual.
    </p>

    <h2>JMX Components</h2>

    <p>Logback-access integrates with JMX servers to publish
    information about its components.
    </p>

    <p>Both <code>RequestLogImpl</code> and <code>LogbackValve</code>
    expose data and can be updated via JMX. A special filter, covered
    further down this document, publishes statistical data on access
    logs.
    </p>


    <h3>Configuring Tomcat for JMX</h3>

    <p>In order to configure Tomcat for JMX, please add the following
    lines to the <em>$TOMCAT_HOME/bin/catalina.sh</em> shell script
    (or its MS Windows equivalent):
    </p>

<div class="source"><pre>CATALINA_OPTS="-Dcom.sun.management.jmxremote"
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.ssl=false"
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"</pre></div>

    <p>After you launch Tomcat, you can access the MBeans exposed by
    Tomcat via the JConsole application, which can be started with the
    following command:
    </p>
    <pre class="source">jconsole</pre>

    <p>If you prefer MX4J to access your components via a web-based
    interface, here is a short summary of the steps to follow. After
    <a href="http://mx4j.sourceforge.net/">downloading MX4J</a>, place
    the <em>mx4j-impl.jar</em> file in the <em>$TOMCAT_HOME/bin/</em>
    directory, and the <em>mx4j-tools.jar</em> file in the
    <em>$TOMCAT_HOME/common/lib/</em> directory. Once that is done,
    add the following lines to the
    <em>$TOMCAT_HOME/bin/catalina.sh</em> shell script:
    </p>

<div class="source"><pre>&lt;!-- at the beginning of the file -->
CATALINA_OPTS="-Dcom.sun.management.jmxremote"
CATALINA_OPTS="$CATALINA_OPTS -Djavax.management.builder.initial=mx4j.server.MX4JMBeanServerBuilder"

&lt;!-- in the "Add on extra jar files to CLASSPATH" section -->
CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div>

    <p>Finally, declare a new <code>Connector</code> in the
      <em>$TOMCAT_HOME/conf/server.xml</em> file: </p>

    <pre class="prettyprint source">&lt;Connector port="8050" 
  handler.list="mx"
  mx.enabled="true" 
  mx.httpHost="localhost" 
  mx.httpPort="8082" 
  protocol="AJP/1.3" /></pre>
  
    <p> Once Tomcat is started, you should be able to reach your JMX
      components by pointing your browser at the following URL:
    </p>

    <pre class="source">http://localhost:8082/</pre>

    <h3>Configuring Jetty</h3>

    <p>
      Configuring Jetty to publish JMX components requires a few modifications to the
      <em>$JETTY_HOME/etc/jetty.xml</em> configuration file. Here are the elements that need to be
      added:
    </p>

    <pre class="prettyprint source">&lt;Call id="MBeanServer" class="java.lang.management.ManagementFactory" name="getPlatformMBeanServer"/>
&lt;!-- initialize the Jetty MBean container -->
&lt;Get id="Container" name="container">
  &lt;Call name="addEventListener">
    &lt;Arg>
      &lt;New class="org.mortbay.management.MBeanContainer">
        &lt;Arg>&lt;Ref id="MBeanServer"/>&lt;/Arg>
        &lt;Set name="managementPort">8082&lt;/Set>
        &lt;Call name="start" />
      &lt;/New>
    &lt;/Arg>
  &lt;/Call>
&lt;/Get></pre>

    <p>Once Jetty is started with this configuration, all available
    components can be reviewed at:
    </p>
    <pre class="prettyprint source">http://localhost:8082/</pre>

    <p>Logback-access' <code>RequestLogImpl</code> should be
    available, including its <code>start()</code> and
    <code>stop()</code> methods.
    </p>


    <h2><a name="teeFilter"
    href="#teeFilter"><code>TeeFilter</code> <span class="small">(a servlet-filter)</span></a></h2>

    <p>In order to diagnose bugs in a web-application, it is often
    handy to capture the client's request as well as the server's
    response. The <code>TeeFilter</code> was designed precisely for
    this purpose. It should be noted that <code>TeeFilter</code> is a
    regular <a
    href="http://download.oracle.com/javaee/5/api/javax/servlet/Filter.html">servlet
    filter</a>. Like other servlet filters, it needs to be declared in
    your web-application's <em>web.xml</em> file:
    </p>

    <pre class="prettyprint source">&lt;filter&gt;
  &lt;filter-name&gt;TeeFilter&lt;/filter-name&gt;
  &lt;filter-class&gt;ch.qos.logback.access.servlet.TeeFilter&lt;/filter-class&gt;
&lt;/filter&gt;

&lt;filter-mapping&gt;
  &lt;filter-name&gt;TeeFilter&lt;/filter-name&gt;
  &lt;url-pattern&gt;/*&lt;/url-pattern&gt;
&lt;/filter-mapping&gt;</pre>

  <p>We have tested <code>TeeFilter</code> to the best of our
  ability. However, since it duplicates the input stream of the
  request and the output stream of the response, it may interfere with
  your application. Moreover, for large input or output sizes, it will
  add measurable latency. Although we have already fixed all currently
  known bugs, <code>TeeFilter</code> has broken otherwise correctly
  behaving applications in the past. Thus, in case of doubt, do not
  hesitate to disable <code>TeeFilter</code>.  
  </p>

  <p>Once <code>TeeFilter</code> is installed, the <a
  href="manual/layouts.html#AccessPatternLayout">PatternLayout </a>
  converters <code>fullRequest</code> and <code>fullResponse</code>
  will output the full contents of the request and respectively the
  response.
  </p>

  <p>Here is a sample logback-access.xml configuration file which will
  output the full contents of the request and response on the console.
  </p>

  <pre class="prettyprint source">&lt;configuration&gt;
  &lt;appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"&gt;
    &lt;encoder&gt;      
      &lt;pattern&gt;%fullRequest%n%n%fullResponse&lt;/pattern&gt;
    &lt;/encoder&gt;
  &lt;/appender&gt;

  &lt;appender-ref ref="STDOUT" /&gt;
&lt;/configuration&gt;</pre>

  <p>Here is the output generated when accessing the <a
  href="demo.html">logback-demo</a> application configured as shown
  above:</p>

  <p class="source"><b>GET /logback-demo/index.jsp HTTP/1.1</b>
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20070312 Firefox/1.5.0
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost:8080/logback-demo/login.jsp
Cookie: JSESSIONID=15c7tqi9ehlwk;  OID324nkzcmr=null; OID32862zgoa=null; 



<b>HTTP/1.1 200 OK</b>
Content-Type: text/html; charset=iso-8859-1
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo


&lt;html&gt;
&lt;head&gt;
        &lt;LINK REL=StyleSheet HREF="css/pk.css" /&gt;
&lt;/head&gt;
&lt;body&gt;

&lt;h2&gt;Logback demo center&lt;/h2&gt;

[snip, so that text is reasonably sized]</p>

  <p>&nbsp;</p>


  <p>As mentioned previously, while extremely useful during problem
  hunting, <code>TeeFilter</code> can introduce new problems.
  Consequently, we do not recommend having <code>TeeFilter</code>
  active in production systems. In order to avoid shipping different
  code for test and production environments, <code>TeeFilter</code>
  supports <code>includes</code> and <code>excludes</code> parameters.
  <code>TeeFilter</code> will be active if the current host is listed
  in the includes list and absent in the excludes list. By special
  convention, an empty includes list is interpreted as to contain all
  possible host names in the universe.
  </p>

  <p>To enable <code>TeeFilter</code> only on the hosts named "orion"
  and "gemini" and disabled elsewhere you would write:</p>

  <pre class="prettyprint source">&lt;filter>
  &lt;filter-name>TeeFilter&lt;/filter-name>
  &lt;filter-class>ch.qos.logback.access.servlet.TeeFilter&lt;/filter-class>
  &lt;init-param>
    <b>&lt;param-name>includes&lt;/param-name></b>
    <b>&lt;param-value>orion, gemini&lt;/param-value></b>
  &lt;/init-param>
&lt;/filter>  </pre>

  <p>To enable <code>TeeFilter</code> on all hosts <em>except</em>
  hosts named "orion" and "gemini" you would write:</p>

  <pre class="prettyprint source">&lt;filter>
  &lt;filter-name>TeeFilter&lt;/filter-name>
  &lt;filter-class>ch.qos.logback.access.servlet.TeeFilter&lt;/filter-class>
  &lt;init-param>
    <b>&lt;param-name>excludes&lt;/param-name></b>
    <b>&lt;param-value>orion, gemini&lt;/param-value></b>
  &lt;/init-param>
&lt;/filter>  </pre>
    

  <script src="templates/footer.js" type="text/javascript"></script>
</div>

</body>
</html>