Author: seb
Date: Wed Dec 6 11:56:07 2006
New Revision: 1066
Added:
logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator.xml
Modified:
logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml
Log:
Corrections after review, one example added
Added:
logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator.xml
==============================================================================
--- (empty file)
+++
logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator.xml
Wed Dec 6 11:56:07 2006
@@ -0,0 +1,20 @@
+<configuration>
+
+ <appender name="STDOUT"
+ class="ch.qos.logback.core.ConsoleAppender">
+ <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
+ <evaluator name="myEval">
+ <expression>event.getStatusCode() ==
404</expression>
+ </evaluator>
+ <OnMismatch>NEUTRAL</OnMismatch>
+ <OnMatch>ACCEPT</OnMatch>
+ </filter>
+ <layout class="ch.qos.logback.access.PatternLayout">
+ <pattern>
+ %h %l %u %t %r %s %b
+ </pattern>
+ </layout>
+ </appender>
+
+ <appender-ref ref="STDOUT" />
+</configuration>
\ No newline at end of file
Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml
==============================================================================
--- logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml
(original)
+++ logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml
Wed Dec 6 11:56:07 2006
@@ -59,7 +59,7 @@
<h2>Logback Classic</h2>
<a name="Filter" />
- <p><code>Filter</code> subclasses all implement the
+ <p><code>Filter</code> objects all implement the
<a
href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a>
abscract class. The <code>decide(Object event)</code> method is
passed a
newly created <code>LoggingEvent</code> object.
@@ -91,7 +91,7 @@
<p>
In logback, <code>Filter</code> objects can only be added to
<code>Appender</code>
instances. By adding filters to an appender you can filter events by
various
- criteria, such as the contents of the log message, the contents of the
NDC,
+ criteria, such as the contents of the log message, the contents of the
MDC,
the time of day or any other part of the logging event.
</p>
@@ -265,16 +265,18 @@
<p>
They are called before the <code>LoggingEvent</code> object
creation. Their
decision is made based on some of the logging event's
components. They require
- no instanciation, nor any other treatement to provide their
+ no logging event instanciation, nor any other treatement to
provide their
filtering functionnalities. They are much more performant than
the usual
<code>Filter</code> objects.
</p>
<p>
Logback classic ships with several <code>TurboFilter</code>
classes ready for use.
- The <code>MDCFilter</code> check the presence of a given value
in the MDC. On the other
- hand, <code>MarkerFilter</code> checks for the presence of a
specific marker attached
- to the logging request.
+ The
+ <a
href="../xref/ch/qos/logback/classic/turbo/MDCFilter.html"><code>MDCFilter</code></a>
+ check the presence of a given value in the MDC. On the other
hand,
+ <a
href="../xref/ch/qos/logback/classic/turbo/MarkerFilter.html"><code>MarkerFilter</code></a>
+ checks for the presence of a specific marker attached to the
logging request.
</p>
<p>
@@ -282,7 +284,8 @@
<code>MarkerFilter</code>.
</p>
-<em>Example 6.1: Basic event evaluator usage
(logback-examples/src/main/java/chapter6/turboFilters.xml)</em>
+<em>Example 6.2: <code>MDCFilter</code> and <code>MarkerFilter</code>
+configuration (logback-examples/src/main/java/chapter6/turboFilters.xml)</em>
<div class="source"><pre><configuration>
<turboFilter class="ch.qos.logback.classic.turbo.MDCFilter">
@@ -318,7 +321,7 @@
<p>
The <code>FilterEvents</code> class creates 10 logging
requests,
- each with its number from 01 to 9. All of the requests
are of level <em>INFO</em>,
+ each with its number from 0 to 9. All of the requests
are of level <em>INFO</em>,
just like the configured overall level, except for two
requests.
The 3rd request, is a <em>DEBUG</em> level
corresponding to the key <em>username</em>.
This obviously satisfies the first
<code>TurboFilter</code> declared in the previous
@@ -353,7 +356,7 @@
<p>
On the other hand, the 6th request, that is a
<em>ERROR</em> level request
should have been displayed. But it satisfied the second
<code>TurboFilter</code>
- whose op was <span class="option">OnMatch</span> option
is set to <em>DENY</em>.
+ whose <span class="option">OnMatch</span> option is set
to <em>DENY</em>.
Thus, the 6th request was not displayed.
</p>
@@ -373,11 +376,37 @@
<p>
<code>EvaluatorFilter</code> objects, with their expressions, are
available to
the access module. However, the variables that one can use to build an
expression
- are different. Only the <code>AccessEvent</code> objects can be used,
by inserting the
+ are different. Only the <code>AccessEvent</code> object can be used, by
inserting the
<em>event</em> variable in the expression. Although less wide than its
classic
counterpart, the access evaluation filter is just as powerfull. All the
request and response components are reachable from the <em>event</em>
variable.
</p>
+
+ <p>
+ Here is a sample configuration that will ensure that any 404 error will
be displayed:
+ </p>
+
+<em>Example 6.3: Access Evaluator
(logback-examples/src/main/java/chapter6/accessEventEvaluator.xml)</em>
+<div class="source"><pre><configuration>
+
+ <appender name="STDOUT"
+ class="ch.qos.logback.core.ConsoleAppender">
+ <b><filter
class="ch.qos.logback.core.filter.EvaluatorFilter">
+ <evaluator name="myEval">
+ <expression>event.getStatusCode() ==
404</expression>
+ </evaluator>
+ <OnMismatch>NEUTRAL</OnMismatch>
+ <OnMatch>ACCEPT</OnMatch>
+ </filter></b>
+ <layout class="ch.qos.logback.access.PatternLayout">
+ <pattern>
+ %h %l %u %t %r %s %b
+ </pattern>
+ </layout>
+ </appender>
+
+ <appender-ref ref="STDOUT" />
+</configuration></pre></div>
_______________________________________________
logback-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-dev
