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>