December 2006 - logback-dev

svn commit: r1068 - logback/tags/release-0.6
by noreply.seb＠qos.ch 06 Dec '06

06 Dec '06

Author: seb Date: Wed Dec 6 15:11:23 2006 New Revision: 1068 Modified: logback/tags/release-0.6/pom.xml Log: corrected SLF4J version Modified: logback/tags/release-0.6/pom.xml ============================================================================== --- logback/tags/release-0.6/pom.xml (original) +++ logback/tags/release-0.6/pom.xml Wed Dec 6 15:11:23 2006 @@ -35,7 +35,7 @@ </dependencies> <properties> - <slf4j.version>1.1.0-RC0</slf4j.version> + <slf4j.version>1.1.0-RC1</slf4j.version> </properties> <dependencyManagement> @@ -84,7 +84,7 @@ <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> - <version>1.1.0-RC0</version> + <version>1.1.0-RC1</version> </dependency> <dependency> <groupId>hsqldb</groupId>

1 0

svn commit: r1067 - in logback/trunk: logback-examples/src/main/java/chapter6 logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 06 Dec '06

06 Dec '06

Author: seb Date: Wed Dec 6 14:51:06 2006 New Revision: 1067 Added: logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator2.xml Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Log: added another examples of filter usage in lb access Added: logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator2.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter6/accessEventEvaluator2.xml Wed Dec 6 14:51:06 2006 @@ -0,0 +1,27 @@ +<configuration> + + <appender name="STDOUT" + class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="Eval404"> + <expression>event.getStatusCode() == 404</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>ACCEPT</OnMatch> + </filter> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="EvalCSS"> + <expression>event.getRequestURI().contains("css")</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>DENY</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 14:51:06 2006 @@ -389,26 +389,59 @@ <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 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" /> + <appender-ref ref="STDOUT" /> </configuration></pre></div> + <p> + We might imagine a slightly more complex use of filters to ensure the display of 404 errors, but + to prevent polluting the output with endless accesses to CSS files. Here is what such a configuration + would look like: + </p> +<em>Example 6.4: Access Evaluator (logback-examples/src/main/java/chapter6/accessEventEvaluator2.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="Eval404"> + <expression>event.getStatusCode() == 404</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>ACCEPT</OnMatch> + </filter> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="EvalCSS"> + <expression>event.getRequestURI().contains("css")</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>DENY</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> + </body> </document> \ No newline at end of file

1 0

svn commit: r1066 - in logback/trunk: logback-examples/src/main/java/chapter6 logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 06 Dec '06

06 Dec '06

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>

1 0

svn commit: r1065 - logback/trunk/logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 06 Dec '06

06 Dec '06

Author: seb Date: Wed Dec 6 10:10:06 2006 New Revision: 1065 Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml Log: chapter 7 Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml ============================================================================== --- logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml (original) +++ logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml Wed Dec 6 10:10:06 2006 @@ -53,7 +53,7 @@ <p> A lighter technique consists of uniquely stamping each log request servicing a given client. Neil Harrison described this method in the book - <em>"Patterns for Logging Diagnostic Messages,"</em> in + <em>Patterns for Logging Diagnostic Messages</em> in Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, and F. Buschmann (Addison-Wesley, 1997). Logback offers a variant of this technique: Mapped Diagnostic Contexts (MDC). @@ -88,7 +88,7 @@ <p> The <code>MDC</code> class contains only static methods. - It lets the developer place information in a “diagnostic context” that can be + It lets the developer place information in a <em>diagnostic context</em> that can be subsequently retrieved by certain logback components. The <code>MDC</code> manages contextual information on a per thread basis. Typically, while starting to service a new client request, the developer will @@ -226,7 +226,7 @@ an RMI Registry on the local host that accepts requests on a well-known port. </p> -<em>Example 7.2: The server side (<a href="../xref/chapter7/NumberCruncherServer.html"> +<em>Example 7.3: The server side (<a href="../xref/chapter7/NumberCruncherServer.html"> logback-examples/src/main/java/chapter7/NumberCruncherServer.java)</a></em> <div class="source"><pre>package chapter7; @@ -386,7 +386,7 @@ <em>number</em>. After computing the distinct factors of the integer parameter, the result is returned to the client. Before returning the result however, the values for the <em>client</em> and <em>number</em> are - cleared by calling the <code>MDC.remove(9</code> method. Normally, + cleared by calling the <code>MDC.remove()</code> method. Normally, a <code>put()</code> operation should be balanced by the corresponding <code>remove()</code> operation. Otherwise, the <code>MDC</code> will contain stale values for certain keys. We would recommend that whenever @@ -404,7 +404,7 @@ <p> The <em>mdc1.xml</em> configuration file is listed below: </p> - +<em>Example 7.4: Configuration file (logback-examples/src/main/java/chapter7/mdc1.xml)</em> <div class="source"><pre><configuration> <appender name="CONSOLE" @@ -440,39 +440,50 @@ <p> Executing multiple instances of the client and requesting the server to factor the numbers 129 from the first client and shortly thereafter - the number 71 from the second client, the server outputs the following (edited to fit): + the number 71 from the second client, the server outputs the following: </p> <div class="source"><pre> -70984 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Beginning to factor. -70984 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 2 as a factor. -71093 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 3 as a factor. -71093 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Found factor 3 -71187 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 4 as a factor. -71297 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 5 as a factor. -71390 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 6 as a factor. -71453 [RMI TCP Connection(5)-192.168.1.6] INFO C:192.168.1.6 N:71 - Beginning to factor. -71453 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 2 as a factor. -71484 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 7 as a factor. -71547 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 3 as a factor. -71593 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 8 as a factor. -71656 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 4 as a factor. -71687 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 9 as a factor. -71750 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 5 as a factor. -71797 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 10 as a factor. -71859 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 6 as a factor. -71890 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 11 as a factor. -71953 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 7 as a factor. -72000 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Found factor 43 -72062 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 8 as a factor. -72156 [RMI TCP Connection(5)-192.168.1.6] INFO C:192.168.1.6 N:71 - Found factor 71</pre></div> - - +<b>70984 [RMI TCP Connection(4)-192.168.1.6] INFO C:orion N:129 - Beginning to factor.</b> +70984 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 2 as a factor. +71093 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 3 as a factor. +71093 [RMI TCP Connection(4)-192.168.1.6] INFO C:orion N:129 - Found factor 3 +71187 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 4 as a factor. +71297 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 5 as a factor. +71390 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 6 as a factor. +<b>71453 [RMI TCP Connection(5)-192.168.1.6] INFO C:orion N:71 - Beginning to factor.</b> +71453 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 2 as a factor. +71484 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 7 as a factor. +71547 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 3 as a factor. +71593 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 8 as a factor. +71656 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 4 as a factor. +71687 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 9 as a factor. +71750 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 5 as a factor. +71797 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 10 as a factor. +71859 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 6 as a factor. +71890 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:orion N:129 - Trying 11 as a factor. +71953 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 7 as a factor. +72000 [RMI TCP Connection(4)-192.168.1.6] INFO C:orion N:129 - Found factor 43 +72062 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:orion N:71 - Trying 8 as a factor. +72156 [RMI TCP Connection(5)-192.168.1.6] INFO C:orion N:71 - Found factor 71</pre></div> + + <p> + The clients were run from a machine called <em>orion</em> as can be seen in + the above output. Even if the server processes the requests of clients + near-simultaneously in separate threads, the logging output pertaining + to each client request can be distinguished by studying the output of the + <code>MDC</code>. Note for example the stamp associated with <em>number</em>, + i.e. the number to factor. + </p> - - - - - + <p> + The attentive reader might have observed that the thread name could + also have been used to distinguish each request. The thread name can cause + confusion if the server side technology recycles threads. In that case, + it may be hard to determine the boundaries of each request, that is, + when a given thread finishes servicing a request and when it begins servicing the next. + Because the <code>MDC</code> is under the control of the application developer, + <code>MDC</code> stamps do not suffer from this problem. + </p> </body> </document> \ No newline at end of file

1 0

[continuum] BUILD SUCCESSFUL: Logback Access Module
by John Noreplai 05 Dec '06

05 Dec '06

Online report : http://localhost:8090/continuum/servlet/continuum/target/ProjectBuild.vm/vi… Build statistics: State: Ok Previous State: Failed Started at: Tue, 5 Dec 2006 16:40:19 +0100 Finished at: Tue, 5 Dec 2006 16:40:34 +0100 Total time: 15s Build Trigger: Schedule Exit code: 0 Building machine hostname: pixie Operating system : Linux(unknown) Java version : 1.5.0_08(Sun Microsystems Inc.) Changes src/main/java/ch/qos/logback/access/filter/mbeans-descriptors.xml **************************************************************************** Output: **************************************************************************** [INFO] Scanning for projects... [INFO] ---------------------------------------------------------------------------- [INFO] Building Logback Access Module [INFO] task-segment: [clean, install] [INFO] ---------------------------------------------------------------------------- [INFO] [clean:clean] [INFO] Deleting directory /opt/continuum-1.0.3/apps/continuum/working-directory/47/target [INFO] Deleting directory /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/classes [INFO] Deleting directory /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] Compiling 56 source files to /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/classes [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] Compiling 22 source files to /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/test-classes [INFO] [surefire:test] [INFO] Surefire report directory: /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/surefire-reports ------------------------------------------------------- T E S T S ------------------------------------------------------- Running ch.qos.logback.access.db.DBAppenderTest [Server@3c6f579]: [Thread[main,5,main]]: checkRunning(false) entered [Server@3c6f579]: [Thread[main,5,main]]: checkRunning(false) exited [Server@3c6f579]: [Thread[main,5,main]]: setDatabaseName(0,test) [Server@3c6f579]: [Thread[main,5,main]]: checkRunning(false) entered [Server@3c6f579]: [Thread[main,5,main]]: checkRunning(false) exited [Server@3c6f579]: [Thread[main,5,main]]: setDatabasePath(0,mem:test;sql.enforce_strict_size=true) [Server@7cf1bb78]: [Thread[main,5,main]]: checkRunning(false) entered [Server@7cf1bb78]: [Thread[main,5,main]]: checkRunning(false) exited [Server@7cf1bb78]: [Thread[main,5,main]]: setDatabaseName(0,test) [Server@7cf1bb78]: [Thread[main,5,main]]: checkRunning(false) entered [Server@7cf1bb78]: [Thread[main,5,main]]: checkRunning(false) exited [Server@7cf1bb78]: [Thread[main,5,main]]: setDatabasePath(0,mem:test;sql.enforce_strict_size=true) [Server@12b7eea]: [Thread[main,5,main]]: checkRunning(false) entered [Server@12b7eea]: [Thread[main,5,main]]: checkRunning(false) exited [Server@12b7eea]: [Thread[main,5,main]]: setDatabaseName(0,test) [Server@12b7eea]: [Thread[main,5,main]]: checkRunning(false) entered [Server@12b7eea]: [Thread[main,5,main]]: checkRunning(false) exited [Server@12b7eea]: [Thread[main,5,main]]: setDatabasePath(0,mem:test;sql.enforce_strict_size=true) [Server@54bb7759]: [Thread[main,5,main]]: checkRunning(false) entered [Server@54bb7759]: [Thread[main,5,main]]: checkRunning(false) exited [Server@54bb7759]: [Thread[main,5,main]]: setDatabaseName(0,test) [Server@54bb7759]: [Thread[main,5,main]]: checkRunning(false) entered [Server@54bb7759]: [Thread[main,5,main]]: checkRunning(false) exited [Server@54bb7759]: [Thread[main,5,main]]: setDatabasePath(0,mem:test;sql.enforce_strict_size=true) Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.913 sec Running ch.qos.logback.access.jetty.JettyBasicTest 2006-12-05 16:40:30.992::INFO: Logging to STDERR via org.mortbay.log.StdErrLog 2006-12-05 16:40:31.037::INFO: jetty-6.0.x |-WARN in ch.qos.logback.access.jetty.RequestLogImpl@13f6ba0f - filename property not set. Assuming [null/etc/logback-access.xml] |-ERROR in ch.qos.logback.access.jetty.RequestLogImpl@13f6ba0f - [null/etc/logback-access.xml] does not exist |-INFO in ch.qos.logback.access.jetty.RequestLogImpl@13f6ba0f - RequestLog added to RequestLogRegistry with name: LogbackRequestLog 2006-12-05 16:40:31.125::INFO: Started SelectChannelConnector @ 0.0.0.0:1234 05/12/2006:16:40:31 +0100 localhost 127.0.0.1 Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.541 sec Running ch.qos.logback.access.filter.AccessStatsTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running ch.qos.logback.access.pattern.ConverterTest Tests run: 16, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec Running ch.qos.logback.access.filter.StatsByDayTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running ch.qos.logback.access.net.URLEvaluatorTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running ch.qos.logback.access.net.SocketAppenderTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.128 sec Results : Tests run: 29, Failures: 0, Errors: 0, Skipped: 0 [INFO] [jar:jar] [INFO] Building jar: /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/logback-access-0.7-SNAPSHOT.jar [INFO] Preparing source:jar [WARNING] Removing: jar from forked lifecycle, to prevent recursive invocation. [INFO] No goals needed for project - skipping [INFO] [source:jar {execution: default}] [INFO] Building jar: /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/logback-access-0.7-SNAPSHOT-sources.jar [INFO] [install:install] [INFO] Installing /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/logback-access-0.7-SNAPSHOT.jar to /root/.m2/repository/ch/qos/logback/logback-access/0.7-SNAPSHOT/logback-access-0.7-SNAPSHOT.jar [INFO] Installing /opt/continuum-1.0.3/apps/continuum/working-directory/47/target/logback-access-0.7-SNAPSHOT-sources.jar to /root/.m2/repository/ch/qos/logback/logback-access/0.7-SNAPSHOT/logback-access-0.7-SNAPSHOT-sources.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------ [INFO] Total time: 13 seconds [INFO] Finished at: Tue Dec 05 16:40:34 CET 2006 [INFO] Final Memory: 15M/143M [INFO] ------------------------------------------------------------------------ ****************************************************************************

1 0

svn commit: r1064 - logback/trunk/logback-access/src/main/java/ch/qos/logback/access/filter
by noreply.seb＠qos.ch 05 Dec '06

05 Dec '06

Author: seb Date: Tue Dec 5 16:31:49 2006 New Revision: 1064 Added: logback/trunk/logback-access/src/main/java/ch/qos/logback/access/filter/mbeans-descriptors.xml Log: mbean descriptor for tomcat Added: logback/trunk/logback-access/src/main/java/ch/qos/logback/access/filter/mbeans-descriptors.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-access/src/main/java/ch/qos/logback/access/filter/mbeans-descriptors.xml Tue Dec 5 16:31:49 2006 @@ -0,0 +1,68 @@ +<?xml version="1.0"?> + +<mbeans-descriptors> + <mbean name="countingFilter" + className="ch.qos.logback.access.filter.StatisticalView" + description="Server statistics" domain="ch.qos.logback.access" + type="ch.qos.logback.access.filter.StatisticalViewImpl"> + + <attribute name="started" description="started state" + type="boolean" writeable="false" /> + + <operation name="stop" + description="Stops the filter" impact="ACTION"> + </operation> + <operation name="start" + description="Starts the filter" impact="ACTION"> + </operation> + <operation name="isStarted" + description="Returns the started state of the filter" impact="ACTION" + return="boolean"> + </operation> + + <operation name="getDailyAverage" + description="Returns the daily average" impact="ACTION" + return="double"> + </operation> + <operation name="getLastDaysCount" + description="Returns the last day's count" impact="ACTION" + return="long"> + </operation> + <operation name="getMonthlyAverage" + description="Returns the monthly average" impact="ACTION" + return="double"> + </operation> + <operation name="getLastMonthsCount" + description="Returns the last month's count" impact="ACTION" + return="long"> + </operation> + <operation name="getTotal" + description="Returns the total accesses" impact="ACTION" + return="long"> + </operation> + <operation name="getWeeklyAverage" + description="Returns the weekly average" impact="ACTION" + return="double"> + </operation> + <operation name="getLastWeeksCount" + description="Returns the last week's count" impact="ACTION" + return="long"> + </operation> + <operation name="getLastMinuteCount" + description="Returns the minute's count" impact="ACTION" + return="long"> + </operation> + <operation name="getMinuteAverage" + description="Returns the minute average" impact="ACTION" + return="double"> + </operation> + <operation name="getHourlyAverage" + description="Returns the hourly average" impact="ACTION" + return="double"> + </operation> + <operation name="getLastHoursCount" + description="Returns the last hour's count" impact="ACTION" + return="long"> + </operation> + </mbean> +</mbeans-descriptors> \ No newline at end of file

1 0

svn commit: r1063 - in logback/trunk: logback-examples/src/main/java/chapter7 logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 05 Dec '06

05 Dec '06

Author: seb Date: Tue Dec 5 16:31:33 2006 New Revision: 1063 Added: logback/trunk/logback-examples/src/main/java/chapter7/ logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncher.java logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherClient.java logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherServer.java logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java logback/trunk/logback-examples/src/main/java/chapter7/mdc1.xml logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Log: On going work on chapter 7 Added: logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncher.java ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncher.java Tue Dec 5 16:31:33 2006 @@ -0,0 +1,26 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * + * Copyright (C) 1999-2006, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ + +package chapter7; + +import java.rmi.Remote; +import java.rmi.RemoteException; + + +/** + * NumberCruncher factors positive integers. + */ +public interface NumberCruncher extends Remote { + /** + * Factor a positive integer <code>number</code> and return its + * <em>distinct</em> factor's as an integer array. + * */ + int[] factor(int number) throws RemoteException; +} Added: logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherClient.java ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherClient.java Tue Dec 5 16:31:33 2006 @@ -0,0 +1,83 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * + * Copyright (C) 1999-2006, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ + +package chapter7; + +import java.io.BufferedReader; +import java.io.InputStreamReader; +import java.rmi.Naming; +import java.rmi.RemoteException; + + +/** + * NumberCruncherClient is a simple client for factoring integers. A + * remote NumberCruncher is contacted and asked to factor an + * integer. The factors returned by the {@link NumberCruncherServer} + * are displayed on the screen. + * */ +public class NumberCruncherClient { + public static void main(String[] args) { + if (args.length == 1) { + try { + String url = "rmi://" + args[0] + "/Factor"; + NumberCruncher nc = (NumberCruncher) Naming.lookup(url); + loop(nc); + } catch (Exception e) { + e.printStackTrace(); + } + } else { + usage("Wrong number of arguments."); + } + } + + static void usage(String msg) { + System.err.println(msg); + System.err.println("Usage: java chapter7.NumberCruncherClient HOST\n" + + " where HOST is the machine where the NumberCruncherServer is running."); + System.exit(1); + } + + static void loop(NumberCruncher nc) { + BufferedReader in = new BufferedReader(new InputStreamReader(System.in)); + int i = 0; + + while (true) { + System.out.print("Enter a number to factor, '-1' to quit: "); + + try { + i = Integer.parseInt(in.readLine()); + } catch (Exception e) { + e.printStackTrace(); + } + + if (i == -1) { + System.out.print("Exiting loop."); + + return; + } else { + try { + System.out.println("Will attempt to factor " + i); + + int[] factors = nc.factor(i); + System.out.print("The factors of " + i + " are"); + + for (int k = 0; k < factors.length; k++) { + System.out.print(" " + factors[k]); + } + + System.out.println("."); + } catch (RemoteException e) { + System.err.println("Could not factor " + i); + e.printStackTrace(); + } + } + } + } +} Added: logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherServer.java ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter7/NumberCruncherServer.java Tue Dec 5 16:31:33 2006 @@ -0,0 +1,159 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * + * Copyright (C) 1999-2006, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ + +package chapter7; + +import java.rmi.RemoteException; +import java.rmi.registry.LocateRegistry; +import java.rmi.registry.Registry; +import java.rmi.server.UnicastRemoteObject; +import java.util.Vector; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import ch.qos.logback.classic.LoggerContext; +import ch.qos.logback.classic.MDC; +import ch.qos.logback.classic.joran.JoranConfigurator; +import ch.qos.logback.core.joran.spi.JoranException; + + +/** + * A simple NumberCruncher implementation that logs its progress when + * factoring numbers. The purpose of the whole exercise is to show the + * use of mapped diagnostic contexts in order to distinguish the log + * output from different client requests. + * */ +public class NumberCruncherServer extends UnicastRemoteObject + implements NumberCruncher { + + private static final long serialVersionUID = 1L; + + static Logger logger = LoggerFactory.getLogger(NumberCruncherServer.class); + + public NumberCruncherServer() throws RemoteException { + } + + public int[] factor(int number) throws RemoteException { + // The client's host is an important source of information. + try { + MDC.put("client", NumberCruncherServer.getClientHost()); + } catch (java.rmi.server.ServerNotActiveException e) { + logger.warn("Caught unexpected ServerNotActiveException.", e); + } + + // The information contained within the request is another source + // of distinctive information. It might reveal the users name, + // date of request, request ID etc. In servlet type environments, + // useful information is contained in the HttpRequest or in the + // HttpSession. + MDC.put("number", String.valueOf(number)); + + logger.info("Beginning to factor."); + + if (number <= 0) { + throw new IllegalArgumentException(number + + " is not a positive integer."); + } else if (number == 1) { + return new int[] { 1 }; + } + + Vector<Integer> factors = new Vector<Integer>(); + int n = number; + + for (int i = 2; (i <= n) && ((i * i) <= number); i++) { + // It is bad practice to place log requests within tight loops. + // It is done here to show interleaved log output from + // different requests. + logger.debug("Trying " + i + " as a factor."); + + if ((n % i) == 0) { + logger.info("Found factor " + i); + factors.addElement(new Integer(i)); + + do { + n /= i; + } while ((n % i) == 0); + } + + // Placing artificial delays in tight-loops will also lead to + // sub-optimal resuts. :-) + delay(100); + } + + if (n != 1) { + logger.info("Found factor " + n); + factors.addElement(new Integer(n)); + } + + int len = factors.size(); + + int[] result = new int[len]; + + for (int i = 0; i < len; i++) { + result[i] = ((Integer) factors.elementAt(i)).intValue(); + } + + // clean up + MDC.remove("client"); + MDC.remove("number"); + + return result; + } + + static void usage(String msg) { + System.err.println(msg); + System.err.println("Usage: java chapter7.NumberCruncherServer configFile\n" + + " where configFile is a logback configuration file."); + System.exit(1); + } + + public static void delay(int millis) { + try { + Thread.sleep(millis); + } catch (InterruptedException e) { + } + } + + public static void main(String[] args) { + if (args.length != 1) { + usage("Wrong number of arguments."); + } + + String configFile = args[0]; + + if (configFile.endsWith(".xml")) { + try { + LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); + JoranConfigurator configurator = new JoranConfigurator(); + configurator.setContext(lc); + lc.shutdownAndReset(); + configurator.doConfigure(args[0]); + } catch (JoranException je) { + je.printStackTrace(); + } + } + + NumberCruncherServer ncs; + + try { + ncs = new NumberCruncherServer(); + logger.info("Creating registry."); + + Registry registry = LocateRegistry.createRegistry(Registry.REGISTRY_PORT); + registry.rebind("Factor", ncs); + logger.info("NumberCruncherServer bound and ready."); + } catch (Exception e) { + logger.error("Could not bind NumberCruncherServer.", e); + + return; + } + } +} Added: logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter7/SimpleMDC.java Tue Dec 5 16:31:33 2006 @@ -0,0 +1,52 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * + * Copyright (C) 1999-2006, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ + +package chapter7; + +import org.slf4j.LoggerFactory; + +import ch.qos.logback.classic.Logger; +import ch.qos.logback.classic.MDC; +import ch.qos.logback.classic.PatternLayout; +import ch.qos.logback.core.ConsoleAppender; + +public class SimpleMDC { + static public void main(String[] args) throws Exception { + // You can put values in the MDC at any time. We first put the + // first name + MDC.put("first", "Dorothy"); + + // Configure logback + PatternLayout layout = new PatternLayout(); + layout.setPattern("%X{first} %X{last} - %m%n"); + layout.start(); + ConsoleAppender appender = new ConsoleAppender(); + appender.setLayout(layout); + appender.start(); + Logger root = (Logger)LoggerFactory.getLogger("root"); + root.addAppender(appender); + + // get a logger + Logger logger = (Logger)LoggerFactory.getLogger(SimpleMDC.class); + + // We now put the last name + MDC.put("last", "Parker"); + + // The most beautiful two words in the English language according + // to Dorothy Parker: + logger.info("Check enclosed."); + logger.debug("The most beautiful two words in English."); + + MDC.put("first", "Richard"); + MDC.put("last", "Nixon"); + logger.info("I am not a crook."); + logger.info("Attributed to the former US president. 17 Nov 1973."); + } +} Added: logback/trunk/logback-examples/src/main/java/chapter7/mdc1.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter7/mdc1.xml Tue Dec 5 16:31:33 2006 @@ -0,0 +1,16 @@ +<?xml version="1.0" encoding="UTF-8" ?> + +<configuration> + + <appender name="CONSOLE" + class="ch.qos.logback.core.ConsoleAppender"> + <layout class="ch.qos.logback.classic.PatternLayout"> + <Pattern>%-4r [%thread] %-5level C:%X{client} N:%X{number} - %msg%n</Pattern> + </layout> + </appender> + + <root> + <level value ="debug"/> + <appender-ref ref="CONSOLE"/> + </root> +</configuration> 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 Tue Dec 5 16:31:33 2006 @@ -157,11 +157,11 @@ </p> <table> - <th> - <td>Name</td> - <td>Type</td> - <td>Description</td> - </th> + <tr> + <th>Name</th> + <th>Type</th> + <th>Description</th> + </tr> <tr> <td>event </td> @@ -285,21 +285,21 @@ <em>Example 6.1: Basic event evaluator usage (logback-examples/src/main/java/chapter6/turboFilters.xml)</em> <div class="source"><pre><configuration> - <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> - <MDCKey>username</MDCKey> - <Value>sebastien</Value> - <OnMatch>ACCEPT</OnMatch> - </turboFilter> + <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> + <MDCKey>username</MDCKey> + <Value>sebastien</Value> + <OnMatch>ACCEPT</OnMatch> + </turboFilter> - <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> - <Marker>billing</Marker> - <OnMatch>DENY</OnMatch> - </turboFilter> + <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> + <Marker>billing</Marker> + <OnMatch>DENY</OnMatch> + </turboFilter> <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date [%thread] %-5level %logger - %msg%n</Pattern> - </layout> + </layout> </appender> <root> @@ -358,7 +358,7 @@ </p> - <h3>Logback Access</h3> + <h2>Logback Access</h2> <p> Logback access benefits from most of the possibilities available @@ -368,7 +368,7 @@ <code>TurboFilter</code> objects are not available to the access module. </p> - <h2>Filters</h2> + <h3>Filters</h3> <p> <code>EvaluatorFilter</code> objects, with their expressions, are available to Added: logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-site/src/site/xdocTemplates/manual/mdc.xml Tue Dec 5 16:31:33 2006 @@ -0,0 +1,478 @@ +<document> + + + <body> + <h2>Chapter 7: Mapped Diagnostic Context</h2> + <div class="author"> + Authors: Ceki Gülcü, Sébastien Pennec + </div> + + <table> + <tr> + <td valign="top" align="top"> + <a rel="license" + href="http://creativecommons.org/licenses/by-nc-sa/2.5/"> + <img alt="Creative Commons License" + style="border-width: 0" + src="http://creativecommons.org/images/public/somerights20.png" /> + </a> + </td> + <td> + <p>Copyright © 2000-2006, QOS.ch</p> + + <p> +  + This work is licensed under a + <a rel="license" + href="http://creativecommons.org/licenses/by-nc-sa/2.5/"> + Creative Commons + Attribution-NonCommercial-ShareAlike 2.5 + License + </a>. +  + </p> + </td> + </tr> + </table> + + <p> + One of the design goals of logback is to audit and debug complex distributed applications. + Most real-world distributed systems need to deal with multiple clients simultaneously. + In a typical multithreaded implementation of such a system, different threads will handle + different clients. A possible but discouraged approach to differentiate the logging output of + one client from another consists of instantiating a new and separate logger for each client. + This technique promotes the proliferation of loggers and considerably increases + their management overhead. + </p> + <p> + A lighter technique consists of uniquely stamping each + log request servicing a given client. Neil Harrison described this method in the book + <em>"Patterns for Logging Diagnostic Messages,"</em> in + Pattern Languages of Program Design 3, edited by R. Martin, D. Riehle, + and F. Buschmann (Addison-Wesley, 1997). Logback offers a variant of this technique: + Mapped Diagnostic Contexts (MDC). + </p> + + <p> + To uniquely stamp each request, the user puts contextual information into the + <code><a href="../xref/ch/qos/logback/classic/MDC.html">MDC</a></code>, + the abbreviation of Mapped Diagnostic Context. + The public interface of the MDC class is shown below. + </p> + +<div class="source"><pre>package ch.qos.logback.classic; + +public class MDC { + //Put a context value as identified by <em>key</em> + //into the current thread's context map. + <b>public static void put(String key, String val);</b> + + //Get the context identified by the <code>key</code> parameter. + <b>public static String get(String key);</b> + + //Remove the the context identified by the <code>key</code> parameter. + <b>public static void remove(String key);</b> + + //Clear all entries in the MDC. + <b>public static void clear();</b> + + //Returns the keys in the MDC as a Set. The returned value can be null. + <b>public static Set<String> getKeys();</b> +}</pre></div> + + <p> + The <code>MDC</code> class contains only static methods. + It lets the developer place information in a “diagnostic context” that can be + subsequently retrieved by certain logback components. The + <code>MDC</code> manages contextual information on a per thread basis. + Typically, while starting to service a new client request, the developer will + insert pertinent contextual information, such as the client id, client's IP + address, request parameters etc. into the <code>MDC</code>. Logback components, + if appropriately configured, will automatically include this information + in each log entry. + </p> + + <p> + The next application named + <code><a href="../xref/chapter7/SimpleMDC.html">SimpleMDC</a></code> + demonstrates this basic principle. + </p> +<em>Example 7.1: Basic MDC usage (<a href="../xref/chapter7/SimpleMDC.html"> +logback-examples/src/main/java/chapter7/SimpleMDC.java)</a></em> +<div class="source"><pre>package chapter7; + +import org.slf4j.LoggerFactory; + +import ch.qos.logback.classic.Logger; +import ch.qos.logback.classic.MDC; +import ch.qos.logback.classic.PatternLayout; +import ch.qos.logback.core.ConsoleAppender; + +public class SimpleMDC { + static public void main(String[] args) throws Exception { + // You can put values in the MDC at any time. We first put the + // first name + <b>MDC.put("first", "Dorothy");</b> + + // Configure logback + PatternLayout layout = new PatternLayout(); + layout.setPattern("%X{first} %X{last} - %m%n"); + layout.start(); + ConsoleAppender appender = new ConsoleAppender(); + appender.setLayout(layout); + appender.start(); + Logger root = (Logger)LoggerFactory.getLogger("root"); + root.addAppender(appender); + + // get a logger + Logger logger = (Logger)LoggerFactory.getLogger(SimpleMDC.class); + + // We now put the last name + <b>MDC.put("last", "Parker");</b> + + // The most beautiful two words in the English language according + // to Dorothy Parker: + logger.info("Check enclosed."); + logger.debug("The most beautiful two words in English."); + + MDC.put("first", "Richard"); + MDC.put("last", "Nixon"); + logger.info("I am not a crook."); + logger.info("Attributed to the former US president. 17 Nov 1973."); + } +}</pre></div> + + <p> + The main method starts by associating the value <em>Dorothy</em> with + the key <em>first</em> in the <code>MDC</code>. You can place as many + value/key associations in the <code>MDC</code> as you wish. + Multiple insertions with the same key will overwrite older values. + The code then proceeds to configure logback. + Note the usage of the <em>%X</em> specifier within the + <code>PatternLayout</code> conversion pattern. The <em>%X</em> + conversion specifier is employed twice, once for the key <em>first</em> + and once for the key <em>last</em>. After configuring the root logger, + the code associates the value <em>Parker</em> with the key <em>last</em>. + It then invokes the logger twice with different messages. + The code finishes by setting the <code>MDC</code> to different values + and issuing several logging requests. Running SimpleMDC yields: + </p> + +<div class="source"><pre>Dorothy Parker - Check enclosed. +Dorothy Parker - The most beautiful two words in English. +Richard Nixon - I am not a crook. +Richard Nixon - Attributed to the former US president. 17 Nov 1973.</pre></div> + + + <p> + The <code>SimpleMDC</code> application illustrates how logback layouts, + if configured appropriately, automatically output <code>MDC</code> information. + Moreover, the information placed into the <code>MDC</code> can be used by + multiple logger invocations. + </p> + + <p> + Mapped Diagnostic Contexts shine brightest within client server architectures. + Typically, multiple clients will be served by multiple threads on the server. + Although the methods in the <code>MDC</code> class are static, + the diagnostic context is managed on a per thread basis, allowing each server + thread to bear a distinct <code>MDC</code> stamp. <code>MDC</code> operations + such as <code>put()</code> and <code>get()</code> affect the <code>MDC</code> + of the <em>current</em> thread only. The <code>MDC</code> in other threads remain + unaffected. Given that <code>MDC</code> information is managed on a + per thread basis, each thread will have its own copy of the <code>MDC</code>. + Thus, there is no need for the developer to worry about thread-safety or + synchronization when programming with the <code>MDC</code> because + it safely and transparently handles these issues. + </p> + + <p> + The next example is somewhat more advanced. + It shows how the <code>MDC</code> can be used in a client-server setting. + The server-side implements the <code>NumberCruncher</code> interface shown in + Example 7.2 below. <code>The NumberCruncher</code> interface contains a single + method named <code>factor()</code>. Using RMI technology, client invokes the + <code>factor()</code> method of the server application to retrieve the distinct + factors of an integer. + </p> + +<em>Example 7.2: The service interface (<a href="../xref/chapter7/NumberCruncher.html"> +logback-examples/src/main/java/chapter7/NumberCruncher.java)</a></em> +<div class="source"><pre>package chapter7; + +import java.rmi.Remote; +import java.rmi.RemoteException; + +/** + * NumberCruncher factors positive integers. + */ +public interface NumberCruncher extends Remote { + /** + * Factor a positive integer <code>number</code> and return its + * <em>distinct</em> factor's as an integer array. + * */ + int[] factor(int number) throws RemoteException; +}</pre></div> + + <p> + The <code>NumberCruncherServer</code> application, listed in Example 7.3 below, + implements the <code>NumberCruncher</code> interface. Its main method exports + an RMI Registry on the local host that accepts requests on a well-known port. + </p> + +<em>Example 7.2: The server side (<a href="../xref/chapter7/NumberCruncherServer.html"> +logback-examples/src/main/java/chapter7/NumberCruncherServer.java)</a></em> +<div class="source"><pre>package chapter7; + +import java.rmi.RemoteException; +import java.rmi.registry.LocateRegistry; +import java.rmi.registry.Registry; +import java.rmi.server.UnicastRemoteObject; +import java.util.Vector; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +import ch.qos.logback.classic.LoggerContext; +import ch.qos.logback.classic.MDC; +import ch.qos.logback.classic.joran.JoranConfigurator; +import ch.qos.logback.core.joran.spi.JoranException; + + +/** + * A simple NumberCruncher implementation that logs its progress when + * factoring numbers. The purpose of the whole exercise is to show the + * use of mapped diagnostic contexts in order to distinguish the log + * output from different client requests. + * */ +public class NumberCruncherServer extends UnicastRemoteObject + implements NumberCruncher { + + private static final long serialVersionUID = 1L; + + static Logger logger = LoggerFactory.getLogger(NumberCruncherServer.class); + + public NumberCruncherServer() throws RemoteException { + } + + public int[] factor(int number) throws RemoteException { + // The client's host is an important source of information. + try { + <b>MDC.put("client", NumberCruncherServer.getClientHost());</b> + } catch (java.rmi.server.ServerNotActiveException e) { + logger.warn("Caught unexpected ServerNotActiveException.", e); + } + + // The information contained within the request is another source + // of distinctive information. It might reveal the users name, + // date of request, request ID etc. In servlet type environments, + // useful information is contained in the HttpRequest or in the + // HttpSession. + <b>MDC.put("number", String.valueOf(number));</b> + + logger.info("Beginning to factor."); + + if (number <= 0) { + throw new IllegalArgumentException(number + + " is not a positive integer."); + } else if (number == 1) { + return new int[] { 1 }; + } + + Vector<Integer> factors = new Vector<Integer>(); + int n = number; + + for (int i = 2; (i <= n) && ((i * i) <= number); i++) { + // It is bad practice to place log requests within tight loops. + // It is done here to show interleaved log output from + // different requests. + logger.debug("Trying " + i + " as a factor."); + + if ((n % i) == 0) { + logger.info("Found factor " + i); + factors.addElement(new Integer(i)); + + do { + n /= i; + } while ((n % i) == 0); + } + + // Placing artificial delays in tight-loops will also lead to + // sub-optimal resuts. :-) + delay(100); + } + + if (n != 1) { + logger.info("Found factor " + n); + factors.addElement(new Integer(n)); + } + + int len = factors.size(); + + int[] result = new int[len]; + + for (int i = 0; i < len; i++) { + result[i] = ((Integer) factors.elementAt(i)).intValue(); + } + + <b>// clean up + MDC.remove("client"); + MDC.remove("number");</b> + + return result; + } + + static void usage(String msg) { + System.err.println(msg); + System.err.println("Usage: java chapter7.NumberCruncherServer configFile\n" + + " where configFile is a logback configuration file."); + System.exit(1); + } + + public static void delay(int millis) { + try { + Thread.sleep(millis); + } catch (InterruptedException e) { + } + } + + public static void main(String[] args) { + if (args.length != 1) { + usage("Wrong number of arguments."); + } + + String configFile = args[0]; + + if (configFile.endsWith(".xml")) { + try { + LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); + JoranConfigurator configurator = new JoranConfigurator(); + configurator.setContext(lc); + lc.shutdownAndReset(); + configurator.doConfigure(args[0]); + } catch (JoranException je) { + je.printStackTrace(); + } + } + + NumberCruncherServer ncs; + + try { + ncs = new NumberCruncherServer(); + logger.info("Creating registry."); + + Registry registry = LocateRegistry.createRegistry(Registry.REGISTRY_PORT); + registry.rebind("Factor", ncs); + logger.info("NumberCruncherServer bound and ready."); + } catch (Exception e) { + logger.error("Could not bind NumberCruncherServer.", e); + + return; + } + } +}</pre></div> + + <p> + The implementation of the <code>factor(int number)</code> method is + of particular relevance. It starts by putting the client's hostname into the + <code>MDC</code> under the key <em>client</em>. The number to factor, + as requested by the client, is put into the <code>MDC</code> under the key + <em>number</em>. After computing the distinct factors of the integer + parameter, the result is returned to the client. Before returning the + result however, the values for the <em>client</em> and <em>number</em> are + cleared by calling the <code>MDC.remove(9</code> method. Normally, + a <code>put()</code> operation should be balanced by the corresponding + <code>remove()</code> operation. Otherwise, the <code>MDC</code> will + contain stale values for certain keys. We would recommend that whenever + possible <code>remove()</code> operations be performed within finally blocks, + ensuring their invocation regardless of the execution path of the code. + </p> + + <p> + After these theoretical explanations, we are ready to run the number + cruncher example. Start the server with the following command: + </p> + +<div class="source"><pre>java chapter7.NumberCruncherServer src/main/java/chapter7/mdc1.xml</pre></div> + + <p> + The <em>mdc1.xml</em> configuration file is listed below: + </p> + +<div class="source"><pre><configuration> + + <appender name="CONSOLE" + class="ch.qos.logback.core.ConsoleAppender"> + <layout class="ch.qos.logback.classic.PatternLayout"> + <Pattern>%-4r [%thread] %-5level <b>C:%X{client} N:%X{number}</b> - %msg%n</Pattern> + </layout> + </appender> + + <root> + <level value ="debug"/> + <appender-ref ref="CONSOLE"/> + </root> +</configuration></pre></div> + + <p> + Note the use of the <em>%X</em> conversion specifier within the + <span class="option">Pattern</span> option. + </p> + + <p> + The following command starts an instance of <code>NumberCruncherClient</code> + application: + </p> + +<div class="source"><pre>java chapter7.NumberCruncherClient <em>hostname</em></pre></div> + + <p> + where <em>hostname</em> is the host where the + <code>NumberCruncherServer</code> is running + </p> + + <p> + Executing multiple instances of the client and requesting the server to factor + the numbers 129 from the first client and shortly thereafter + the number 71 from the second client, the server outputs the following (edited to fit): + </p> + +<div class="source"><pre> +70984 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Beginning to factor. +70984 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 2 as a factor. +71093 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 3 as a factor. +71093 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Found factor 3 +71187 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 4 as a factor. +71297 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 5 as a factor. +71390 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 6 as a factor. +71453 [RMI TCP Connection(5)-192.168.1.6] INFO C:192.168.1.6 N:71 - Beginning to factor. +71453 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 2 as a factor. +71484 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 7 as a factor. +71547 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 3 as a factor. +71593 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 8 as a factor. +71656 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 4 as a factor. +71687 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 9 as a factor. +71750 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 5 as a factor. +71797 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 10 as a factor. +71859 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 6 as a factor. +71890 [RMI TCP Connection(4)-192.168.1.6] DEBUG C:192.168.1.6 N:129 - Trying 11 as a factor. +71953 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 7 as a factor. +72000 [RMI TCP Connection(4)-192.168.1.6] INFO C:192.168.1.6 N:129 - Found factor 43 +72062 [RMI TCP Connection(5)-192.168.1.6] DEBUG C:192.168.1.6 N:71 - Trying 8 as a factor. +72156 [RMI TCP Connection(5)-192.168.1.6] INFO C:192.168.1.6 N:71 - Found factor 71</pre></div> + + + + + + + + + </body> +</document> \ No newline at end of file

1 0

svn commit: r1062 - logback/trunk/logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 04 Dec '06

04 Dec '06

Author: seb Date: Mon Dec 4 16:33:37 2006 New Revision: 1062 Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Log: on going work 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 Mon Dec 4 16:33:37 2006 @@ -153,6 +153,83 @@ </p> <p> + The variables available to the <code>EventEvaluator</code> are descripbed below: + </p> + + <table> + <th> + <td>Name</td> + <td>Type</td> + <td>Description</td> + </th> + <tr> + <td>event + </td> + <td><code>LoggingEvent</code></td> + <td>The newly created logging event. + </td> + </tr> + <tr> + <td>message + </td> + <td><code>String</code></td> + <td>The message created with the logging request. + </td> + </tr> + <tr> + <td>logger + </td> + <td><code>LoggerRemoteView</code></td> + <td>This object can be treated like a usual logger. In case the logging event + is serialized and sent to a remote machine, the usual logger object is + dropped and replaced by a <code>LoggerRemoteView</code> object, which + performs much better over the wire. + </td> + </tr> + <tr> + <td>level + </td> + <td><code>int</code></td> + <td>The int value corresponding to the level. To help create easily + expressions involving levels, the default value <em>DEBUG</em>, + <em>INFO</em>, <em>WARN</em> and <em>ERROR</em> are also available. Thus, + using <em>level > INFO</em> is a correct expression. + </td> + </tr> + <tr> + <td>timeStamp + </td> + <td><code>long</code></td> + <td>The timestamp corresponding to the logging event's creation. + </td> + </tr> + <tr> + <td>marker + </td> + <td><code>Marker</code></td> + <td>The <code>Marker</code> object associated with the logging request. + </td> + </tr> + <tr> + <td>mdc + </td> + <td><code>Map</code></td> + <td>A map containing all the MDC values at the time of the + creation of the logging event. A value can be access by using the + following expression: <em>mdc.get("myKey")</em>. + </td> + </tr> + <tr> + <td>throwable + </td> + <td><code>Throwable</code></td> + <td>The exception that was passed to the logger when it + was requested. + </td> + </tr> + </table> + + <p> The behaviour of the filter is also defined by its <span class="option">OnMatch</span> and <span class="option">OnMismatch</span> options. The configuration specifies thanks to these elements the replies that the <code>EvaluatorFilter</code> must give once its @@ -281,9 +358,26 @@ </p> - <h2>Logback Access</h2> + <h3>Logback Access</h3> - <h3>Filters</h3> + <p> + Logback access benefits from most of the possibilities available + to the classic module. <code>Filter</code> objects are available and work + in the same way as their classic counterpart. They handle access' implementation + of logging events: <code>AccessEvent</code>. On the other hand, + <code>TurboFilter</code> objects are not available to the access module. + </p> + + <h2>Filters</h2> + + <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 + <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>

1 0

svn commit: r1061 - in logback/trunk: logback-examples/src/main/java/chapter6 logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 04 Dec '06

04 Dec '06

Author: seb Date: Mon Dec 4 15:25:04 2006 New Revision: 1061 Added: logback/trunk/logback-examples/src/main/java/chapter6/FilterEvents.java logback/trunk/logback-examples/src/main/java/chapter6/turboFilters.xml Modified: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Log: more documentation and examples on chapter 6 Added: logback/trunk/logback-examples/src/main/java/chapter6/FilterEvents.java ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter6/FilterEvents.java Mon Dec 4 15:25:04 2006 @@ -0,0 +1,43 @@ +package chapter6; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; +import org.slf4j.Marker; +import org.slf4j.MarkerFactory; + +import ch.qos.logback.classic.LoggerContext; +import ch.qos.logback.classic.MDC; +import ch.qos.logback.classic.joran.JoranConfigurator; +import ch.qos.logback.core.joran.spi.JoranException; + +public class FilterEvents { + + public static void main(String[] args) throws InterruptedException { + Logger logger = (Logger) LoggerFactory.getLogger(FilterEvents.class); + LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); + + try { + JoranConfigurator configurator = new JoranConfigurator(); + configurator.setContext(lc); + lc.shutdownAndReset(); + configurator.doConfigure(args[0]); + } catch (JoranException je) { + je.printStackTrace(); + } + + for (int i = 0; i < 10; i++) { + if (i == 3) { + MDC.put("username", "sebastien"); + logger.debug("logging statement " + i); + MDC.remove("username"); + } else if (i == 6) { + Marker billing = MarkerFactory.getMarker("billing"); + logger.error(billing, "logging statement " + i); + } else { + logger.info("logging statement " + i); + } + } + + //StatusPrinter.print(lc.getStatusManager()); + } +} Added: logback/trunk/logback-examples/src/main/java/chapter6/turboFilters.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter6/turboFilters.xml Mon Dec 4 15:25:04 2006 @@ -0,0 +1,26 @@ +<?xml version="1.0" encoding="UTF-8" ?> + +<configuration> + + <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> + <MDCKey>username</MDCKey> + <Value>sebastien</Value> + <OnMatch>ACCEPT</OnMatch> + </turboFilter> + + <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> + <Marker>billing</Marker> + <OnMatch>DENY</OnMatch> + </turboFilter> + + <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> + <layout class="ch.qos.logback.classic.PatternLayout"> + <Pattern>%date [%thread] %-5level %logger - %msg%n</Pattern> + </layout> + </appender> + + <root> + <level value="info"/> + <appender-ref ref="console" /> + </root> +</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 Mon Dec 4 15:25:04 2006 @@ -56,13 +56,16 @@ <code>TurboFilter</code>. </p> + <h2>Logback Classic</h2> + <a name="Filter" /> <p><code>Filter</code> subclasses all implement the <a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> - abscract class. + abscract class. The <code>decide(Object event)</code> method is passed a + newly created <code>LoggingEvent</code> object. </p> - <h2>Filter chains</h2> + <h3>Filter chains</h3> <p> This abstract class assumes that filters be organized in a linear chain. Its member field next points to the next filter in the chain, or @@ -102,6 +105,7 @@ flexibility in the way that you can affect the logging event's filtering. </p> + <a name="EventEvaluator" /> <h3>Event Evaluators</h3> <p> @@ -114,7 +118,7 @@ Let's see a sample configuration. </p> -<em>Example 6.1: Basic event evaluator usage</em> +<em>Example 6.1: Basic event evaluator usage (logback-examples/src/main/java/chapter6/basicEventEvaluator.xml)</em> <div class="source"><pre><configuration> <appender name="STDOUT" @@ -158,9 +162,128 @@ logging event should be accepted, or rejected. </p> + + <a name="TurboFilter" /> + <h3>TurboFilters</h3> + + <p> + <code>TurboFilter</code> objects all extend the + <a href="../xref/ch/qos/logback/classic/turbo/TurboFilter.html"> + <code>TurboFilter</code></a> abstract class. Like the usual filters, they + use ternary logic to return their evaluation of the logging event. + </p> + + <p> + Overall, they work much like the previously mentionned filters. However, + there are two main differences between <code>Filter</code> and + <code>TurboFilter</code> objects. + </p> + + <p> + <code>TurboFilter</code> objects are tied to the logging context. Hence, they + are called not only when a given appender is used, but each and every time a logging + request is issued. Their scope is wider than appender-attached filters. + </p> + + <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 + 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. + </p> + + <p> + Here is a sample configuration, using both <code>MDCFilter</code> and + <code>MarkerFilter</code>. + </p> + +<em>Example 6.1: Basic event evaluator usage (logback-examples/src/main/java/chapter6/turboFilters.xml)</em> +<div class="source"><pre><configuration> + + <turboFilter class="ch.qos.logback.classic.turbo.MDCFilter"> + <MDCKey>username</MDCKey> + <Value>sebastien</Value> + <OnMatch>ACCEPT</OnMatch> + </turboFilter> + + <turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter"> + <Marker>billing</Marker> + <OnMatch>DENY</OnMatch> + </turboFilter> + + <appender name="console" class="ch.qos.logback.core.ConsoleAppender"> + <layout class="ch.qos.logback.classic.PatternLayout"> + <Pattern>%date [%thread] %-5level %logger - %msg%n</Pattern> + </layout> + </appender> + + <root> + <level value="info"/> + <appender-ref ref="console" /> + </root> +</configuration></pre></div> + + <p> + You can see this configuration in action by issuing the following command: + </p> + +<div class="source"><pre> +java chapter6.FilterEvents src/java/main/chapter6/turboFilters.xml +</pre></div> + + <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>, + 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 + configuration file. The 6th request is a <em>ERROR</em> level request, + which is issued along with the <em>billing</em> marker, to match + the requests for the second declared <code>TurboFilter</code>. + </p> + + <p> + Here is the output of the previous command: + </p> + +<div class="source"><pre> +2006-12-04 15:17:22,859 [main] INFO chapter6.FilterEvents - logging statement 0 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 1 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 2 +2006-12-04 15:17:22,875 [main] DEBUG chapter6.FilterEvents - logging statement 3 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 4 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 5 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 7 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 8 +2006-12-04 15:17:22,875 [main] INFO chapter6.FilterEvents - logging statement 9 +</pre></div> + + + <p> + One can see that the 3rd request, who should not be displayed if we + only followed the overall <em>INFO</em> level, appears anyway, because + it matched the first <code>TurboFilter</code> requirements and was accepted. + </p> + + <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>. + Thus, the 6th request was not displayed. + </p> + <h2>Logback Access</h2> + <h3>Filters</h3>

1 0

svn commit: r1060 - in logback/trunk: logback-examples/src/main/java/chapter6 logback-site/src/site/resources/manual/images/chapter6 logback-site/src/site/xdocTemplates/manual
by noreply.seb＠qos.ch 04 Dec '06

04 Dec '06

Author: seb Date: Mon Dec 4 11:55:59 2006 New Revision: 1060 Added: logback/trunk/logback-examples/src/main/java/chapter6/ logback/trunk/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml logback/trunk/logback-site/src/site/resources/manual/images/chapter6/ logback/trunk/logback-site/src/site/resources/manual/images/chapter6/filterChain.gif (contents, props changed) logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Log: First draft of chapter 6 Added: logback/trunk/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-examples/src/main/java/chapter6/basicEventEvaluator.xml Mon Dec 4 11:55:59 2006 @@ -0,0 +1,23 @@ +<configuration> + + <appender name="STDOUT" + class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="myEval"> + <expression>message.contains("important")</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>ACCEPT</OnMatch> + </filter> + <layout class="ch.qos.logback.classic.PatternLayout"> + <pattern> + %-4relative [%thread] %-5level %logger - %msg%n + </pattern> + </layout> + </appender> + + <root> + <level value="INFO" /> + <appender-ref ref="STDOUT" /> + </root> +</configuration> \ No newline at end of file Added: logback/trunk/logback-site/src/site/resources/manual/images/chapter6/filterChain.gif ============================================================================== Binary file. No diff available. Added: logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml ============================================================================== --- (empty file) +++ logback/trunk/logback-site/src/site/xdocTemplates/manual/filters.xml Mon Dec 4 11:55:59 2006 @@ -0,0 +1,168 @@ +<document> + + + <body> + <h2>Chapter 6: Filters</h2> + <div class="author"> + Authors: Ceki Gülcü, Sébastien Pennec + </div> + + <table> + <tr> + <td valign="top" align="top"> + <a rel="license" + href="http://creativecommons.org/licenses/by-nc-sa/2.5/"> + <img alt="Creative Commons License" + style="border-width: 0" + src="http://creativecommons.org/images/public/somerights20.png" /> + </a> + </td> + <td> + <p>Copyright © 2000-2006, QOS.ch</p> + + <p> +  + This work is licensed under a + <a rel="license" + href="http://creativecommons.org/licenses/by-nc-sa/2.5/"> + Creative Commons + Attribution-NonCommercial-ShareAlike 2.5 + License + </a>. +  + </p> + </td> + </tr> + </table> + + <p> + As we have seen, logback has several built-in ways for filtering log requests, + including the context-wide filter, logger-level selection rule and appender filters. + These provide high performance filtering for the most commonly encountered + cases. These filters are largely inspired from Linux ipchains or + iptables as they are called in more recent Linux kernels. + Logback filters are based on ternary logic allowing them to be assembled or chained + together to compose an arbitrarily complex filtering policy. + </p> + + <p> + There are two main types of filters, namely <code>Filter</code> and + <code>TurboFilter</code>. + </p> + + <a name="Filter" /> + <p><code>Filter</code> subclasses all implement the + <a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> + abscract class. + </p> + + <h2>Filter chains</h2> + <p> + This abstract class assumes that filters be organized in a linear chain. + Its member field next points to the next filter in the chain, or + <code>null</code> if there are no further filters in the chain. + Figure 6.1 depicts a sample filter chain consisting of three filters. + </p> + + <img src="images/chapter6/filterChain.gif" alt="A sample filter chain"/> + + <p> + Filters are based on ternary logic. The <code>decide(Object event)</code> + method of each filter is called in sequence. This method returns one of the + enumerations <code>FilterReply.DENY</code>, <code>FilterReply.NEUTRAL</code> or + <code>FilterReply.ACCEPT</code>. If the returned value is <code>FilterReply.DENY</code>, + then the log event is dropped immediately without consulting the + remaining filters. If the value returned is <code>FilterReply.NEUTRAL</code>, + then the next filter in the chain is consulted. If there are no further filters + to consult, then the logging event is processed normally. + If the returned value is <code>FilterReply.ACCEPT</code>, then the logging + event is processed immediately skipping the remaining filters. + </p> + + <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, + the time of day or any other part of the logging event. + </p> + + <p> + The criteria can be specified using an expression evaluator. The + <a href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"> + <code>EvaluatorFilter</code></a> class uses an + <a href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> + <code>EventEvaluator</code></a> + to decide wether to accept or deny the request. This allows unprecedented + flexibility in the way that you can affect the logging event's filtering. + </p> + + <h3>Event Evaluators</h3> + + <p> + Events evaluators allow the user to enter java expressions, using + components of a logging event, and to check each logging event + against the compiled expression. + </p> + + <p> + Let's see a sample configuration. + </p> + +<em>Example 6.1: Basic event evaluator usage</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>message.contains("important")</expression> + </evaluator> + <OnMismatch>NEUTRAL</OnMismatch> + <OnMatch>ACCEPT</OnMatch> + </filter></b> + <layout class="ch.qos.logback.classic.PatternLayout"> + <pattern> + %-4relative [%thread] %-5level %logger - %msg%n + </pattern> + </layout> + </appender> + + <root> + <level value="INFO" /> + <appender-ref ref="STDOUT" /> + </root> +</configuration></pre></div> + + <p> + The bold part in the previous configuration adds an <code>EvaluatorFilter</code> + to a <code>ConsoleAppender</code>. An <code>EventEvaluator</code> is then given to + the filter. The <em>expression</em> element contains a recognizable java expression. + Notice that the <em>message</em> variable is not defined anywhere. Logback provides + access to the internal components of a logging event and lets the user build her + expression at will. + </p> + + <p> + The behaviour of the filter is also defined by its <span class="option">OnMatch</span> + and <span class="option">OnMismatch</span> options. The configuration specifies thanks + to these elements the replies that the <code>EvaluatorFilter</code> must give once its + expression has been evaluated. The example above returns a positive reply when the + message of the logging event contains the String <em>important</em>. If this String is + not found in the message, then the filter lets the next filter evaluate whether this + logging event should be accepted, or rejected. + </p> + + + + + + + + </body> +</document> \ No newline at end of file

1 0