This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via 1c9ce863a577cf5075088eb66ca5353f4de0e209 (commit) via 3fc80dba66c065f80cb098f12916884982205785 (commit) from 474f6003528b4f84583c148a9f9b98c014aa196c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=1c9ce863a577cf5075088eb66... http://github.com/ceki/logback/commit/1c9ce863a577cf5075088eb66ca5353f4de0e2... commit 1c9ce863a577cf5075088eb66ca5353f4de0e209 Author: Ceki Gulcu <ceki@qos.ch> Date: Fri Nov 26 13:11:17 2010 +0100 logback-access documentation improvements diff --git a/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png b/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png new file mode 100644 index 0000000..f64f635 Binary files /dev/null and b/logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png differ http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=3fc80dba66c065f80cb098f12... http://github.com/ceki/logback/commit/3fc80dba66c065f80cb098f129168849822057... commit 3fc80dba66c065f80cb098f12916884982205785 Author: Ceki Gulcu <ceki@qos.ch> Date: Fri Nov 26 13:10:56 2010 +0100 logback-access documentaiton improvements diff --git a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml index 513cdd7..df0d56f 100644 --- a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml +++ b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml @@ -1,20 +1,17 @@ <configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> - <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 name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator> + <expression>event.getStatusCode() == 404</expression> + </evaluator> + <onMismatch>DENY</onMismatch> + <onMatch>ACCEPT</onMatch> + </filter> - <appender-ref ref="STDOUT" /> + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> + </appender> + + <appender-ref ref="STDOUT" /> </configuration> \ No newline at end of file diff --git a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml index 116061a..617e940 100644 --- a/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml +++ b/logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml @@ -1,27 +1,21 @@ <configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> - <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 name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <evaluator name="Eval404"> + <expression> + (event.getStatusCode() == 404) + && <!-- ampersand characters need to be escaped --> + !(event.getRequestURI().contains(".css")) + </expression> + </evaluator> + <onMismatch>DENY</onMismatch> + <onMatch>ACCEPT</onMatch> + </filter> - <appender-ref ref="STDOUT" /> -</configuration> \ No newline at end of file + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> + </appender> + + <appender-ref ref="STDOUT" /> +</configuration> diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html index b0c3de9..e639bf1 100644 --- a/logback-site/src/site/pages/access.html +++ b/logback-site/src/site/pages/access.html @@ -417,51 +417,17 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div> </p> - <h2><code>CountingFilter</code></h2> - - <p>With the help of <a - href="xref/ch/qos/logback/access/filter/CountingFilter.html"><code>CountingFilter</code></a> - class, logback-access can provide statistical data about access to - the web-server. - </p> - - <p>If you wish to make use of <code>CountingFilter</code>, you to - declare it, as any other filter: - </p> - - <pre class="prettyprint source"><configuration> - <b><filter class="ch.qos.logback.access.filter.CountingFilter"> - <name>countingFilter</name> - </filter></b> - - <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <encoder> - <pattern>%h %l %u %t \"%r\" %s %b</pattern> - </encoder> - </appender> - - <appender-ref ref="STDOUT" /> -</configuration></pre> - - <p>This component registers itself to the JMX server and publishes - the statistical data such as averages by minute, by hour, by day, - by week, and by month. Last month's, week's, day's, hour's and - minute's counts as well as the total number of access are also - exposed. - </p> - - - <h2><a name="teeFilter" href="#teeFilter"><code>TeeFilter</code></a></h2> + <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 as is. The <code>TeeFilter</code> was designed precisely - for this purpose. - </p> - - <p>The <code>TeeFilter</code> is a regular servlet filter. Like other - servlet filters, it needs to be declared in your web-application's - <em>web.xml</em> file: + 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"><filter> diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html index b698e74..5ae6f91 100644 --- a/logback-site/src/site/pages/manual/filters.html +++ b/logback-site/src/site/pages/manual/filters.html @@ -247,18 +247,21 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p><a href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a> - is a generic filter encapsulating an <a + is a generic filter encapsulating an + <code>EventEvaluator</code>. As the name intimates, an + <a href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> - <code>EventEvaluator</code></a> which evaluates whether a given - criteria is met. On match and respectively on mismatch, the - <code>EvaluatorFilter</code> will return the value corresponding - to <span class="option">onMatch</span> and respectively to <span - class="option">onMismatch</span> properties. + <code>EventEvaluator</code></a> evaluates whether a given criteria + is met for a given event. On match and respectively on mismatch, + the hosting <code>EvaluatorFilter</code> will return the value + specified by <span class="option">onMatch</span> and respectively + to <span class="option">onMismatch</span> properties. </p> - <p>The <code>EventEvaluator</code> is an abstract class and you + + <p>Note that <code>EventEvaluator</code> is an abstract class. You can implement your own event evaluation logic by sub-classing - <code>EventEvaluator</code>. + <code>EventEvaluator</code>. </p> @@ -363,11 +366,11 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p>Logback-classic ships with another concrete <code>EventEvaluator</code> implementation called <a href="../xref/ch/qos/logback/classic/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a> - which taking artibtrary java language boolean expressions as the + taking arbitrary java language boolean expressions as the evaluation criteria. We refer to such java language boolean - expressions as "<em>evaulation expressions</em>". Evaluation + expressions as "<em>evaluation expressions</em>". Evaluation expressions enable great flexibility in event - filtering.<code>JaninoEventEvaluator</code> requires the <a + filtering. <code>JaninoEventEvaluator</code> requires the <a href="http://docs.codehaus.org/display/JANINO/Home">Janino library</a>. Please see the <a href="../setup.html#janino">corresponding section</a> of the setup @@ -381,14 +384,15 @@ public class SampleFilter extends Filter>ILoggingEvent> { <p>Evaluation expressions are compiled on-the-fly during the interpretation of the configuration file. As a user, you do not need to worry about the actual plumbing. However, it is your - reponsibility to ensure that the java-language expression is - boolean, that it evaluates to true or false. </p> + reponsibility to ensure that the java-language expression returns + a boolean, i.e. that it evaluates to true or false. </p> - <p>Given that an evaluation expression acts on the current logging - event, logback automatically exports various fields of the logging - event as variables accessible from the evaluation expression. The - case-sensitive names these variables is listed below. + <p>The evaluation expression is evaluated on the current logging + event. Logback-classic automatically exports various fields of the + logging event as variables accessible from the evaluation + expression. The case-sensitive names of these exported variables + are listed below. </p> <table class="bodyTable"> @@ -1002,85 +1006,158 @@ logger.debug("Hello {}.", name1);</pre> because only 5 repetitions are allowed by default. </p> - <h2>In logback-access</h2> + <h1><a name="logbac-access" href="#logback-access">In logback-access</a></h1> <p>Logback-access offers most of the features available with - logback-classic. <code>Filter</code> objects are available and - work in the same way as their logback-classic counterparts. They - handle access' implementation of logging events: - <code>AccessEvent</code>. Thus, a customized filter for logback - access follows strictly the same rules as those for - logback-classic, except for the event type received as parameter. - On the other hand, <code>TurboFilter</code> objects are supported - by logback-access. + logback-classic. In particular, <code>Filter</code> objects are + available and work in the same way as their logback-classic + counterparts, with one notable difference. Instead of + <code>LoggingEvent</code> instances logback-access filters act + upon <a + href="../xref/ch/qos/logback/access/spi/AccessEvent.html"><code>AccessEvent</code></a> + instances. At present time, logback-access ships with a limited + number of filters described below. If you would like to suggest + additional filters, please contact the logback-dev mailing list. </p> + + <h2><a name="countingFilter" + href="#countingFilter"><code>CountingFilter</code></a></h2> + + <p>With the help of <a + href="xref/ch/qos/logback/access/filter/CountingFilter.html"><code>CountingFilter</code></a> + class, logback-access can provide statistical data about access to + the web-server. Upon initialization, <code>CountingFilter</code> + registers itself as an MBean onto the platform's JMX server. You + can then interrogate that MBean for statistical data, + e.g. averages by minute, hour, day, week, or month. Other + statistics such the count for the preceding week, day, hour or + month as well as the total count are also available. + </p> + + <p>The following <em>logback-access.xml</em> configuration file + declares a <code>CountingFilter</code>. </p> + + <pre class="prettyprint source"><configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <b><filter class="ch.qos.logback.access.filter.CountingFilter"> + <name>countingFilter</name> + </filter></b> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <encoder> + <pattern>%h %l %u %t \"%r\" %s %b</pattern> + </encoder> + </appender> + + <appender-ref ref="STDOUT" /> +</configuration></pre> + + <p>You can examine the various statistics maintained by + <code>CountingFilter</code> on your platform's JMX server via the + <code>jconsole</code> application. </p> + + + <img alt="CountingFilter via jconsole" src="images/chapters/filters/countingFilter.png" /> + + <h3><a name="access_EvalutorFilter" + href="#access_EvalutorFilter"><code>EvaluatorFilter</code></a></h3> + - <h3>Filters</h3> - - <p><code>EvaluatorFilter</code> objects with java expressions - supplied in in <code>evaluator</code> configuration elements are - supported by logback-access. However, list implicit variables - available for constructing an expression are different. Only the - <code>AccessEvent</code> object can be used by inserting the - <em>event</em> variable in the expression. Nevertheless the access - <code>evaluator</code> 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 logged: + <p><a + href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a> + is a generic filter encapsulating an + <code>EventEvaluator</code>. As the name intimates, an + <a + href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"> + <code>EventEvaluator</code></a> evaluates whether a given criteria + is met for a given event. On match and respectively on mismatch, + the hosting <code>EvaluatorFilter</code> will return the value + specified by <span class="option">onMatch</span> and respectively + to <span class="option">onMismatch</span> properties. Note that + <code>EvaluatorFilter</code> has been previously discussed in the + context of logback-classic (<a href="#evalutatorFilter">see + above</a>). The present text is mostly a repetition of the + previous discussion.</p> + + + <p>Note that <code>EventEvaluator</code> is an abstract class. You + can implement your own event evaluation logic by sub-classing + <code>EventEvaluator</code>. Logback-access ships with a concrete + implementation named <a + href="../xref/ch/qos/logback/access/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a>. + It takes arbitrary java language boolean expressions as the + evaluation criteria. We refer to such java language boolean + expressions as "<em>evaluation expressions</em>". Evaluation + expressions enable great flexibility in event + filtering. <code>JaninoEventEvaluator</code> requires the <a + href="http://docs.codehaus.org/display/JANINO/Home">Janino + library</a>. Please see the <a + href="../setup.html#janino">corresponding section</a> of the setup + document. + </p> + + <p>Evaluation expressions are compiled on-the-fly during the + interpretation of the configuration file. As a user, you do not + need to worry about the actual plumbing. However, it is your + reponsibility to ensure that the java-language expression returns + a boolean, i.e. that it evaluates to true or false. </p> + + + <p>The evaluation expression is evaluated on the current access + event. Logback-access automatically exports the current + <code>AccessEvent</code> instance under the variable name + <b><code>event</code></b>. You can read the various data + associated with the HTTP request as well as the HTTP response via + the <code>event</code> variable. Please refer to the the <a + href="../xref/ch/qos/logback/access/spi/AccessEvent.html"><code>AccessEvent</code> + class source code</a> for the exact list. </p> + + <p>The next logback-access configuration file illustrates + filtering based on the <a + href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5">404 + (Not Found)</a> HTTP response code. Every request resulting in a + 404 will be printed on the console.</p> <em>Example: Access Evaluator (logback-examples/src/main/java/chapters/filters/accessEventEvaluator.xml)</em> <pre class="prettyprint source"><configuration> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <b><filter class="ch.qos.logback.core.filter.EvaluatorFilter"> - <evaluator name="myEval"> + <evaluator> <expression>event.getStatusCode() == 404</expression> </evaluator> - <onMismatch>NEUTRAL</onMismatch> - <onMatch>ACCEPT</onMatch> + <onMismatch>DENY</onMismatch> </filter></b> - <encoder> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </encoder> + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> </appender> <appender-ref ref="STDOUT" /> </configuration></pre> - <p>We might imagine a slightly more complex use of filters to - ensure logging of 404 errors, except those returned on access to - CSS resources. Here is what such a configuration would look like: + <p>In the next example, we still log request resulting 404 errors, + except those requests asking for CSS files. </p> + <em>Example 6.10: Access Evaluator (logback-examples/src/main/java/chapters/filters/accessEventEvaluator2.xml)</em> <pre class="prettyprint source"><configuration> - + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <b><filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> <evaluator name="Eval404"> - <expression>event.getStatusCode() == 404</expression> + <expression> + <b>(event.getStatusCode() == 404)</b> + <b>&amp;&amp;</b> <!-- ampersand characters need to be escaped --> + <b>!(event.getRequestURI().contains(".css"))</b> + </expression> </evaluator> - <onMismatch>NEUTRAL</onMismatch> - <onMatch>ACCEPT</onMatch> + <onMismatch>DENY</onMismatch> </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> - <encoder> - <pattern> - %h %l %u %t %r %s %b - </pattern> - </encoder> + + <encoder><pattern>%h %l %u %t %r %s %b</pattern></encoder> </appender> <appender-ref ref="STDOUT" /> diff --git a/logback-site/src/site/pages/recipes/captureHttp.html b/logback-site/src/site/pages/recipes/captureHttp.html index 5e925fb..244478a 100644 --- a/logback-site/src/site/pages/recipes/captureHttp.html +++ b/logback-site/src/site/pages/recipes/captureHttp.html @@ -38,8 +38,8 @@ </p> <p>Certain Web-Service stacks can be easily configured to log - the SOAP traffic. For instance, with JBoss' Web-services stack, - you can set the level of the + SOAP traffic. For instance, with JBoss' Web-services stack, you + can set the level of the <code>org.jboss.ws.core.MessageTrace</code> logger to <code>TRACE</code> in order to enable SOAP message tracing as <a href="http://community.jboss.org/wiki/JBossWS-Log4j">documented @@ -48,7 +48,7 @@ <p>If you are using a different Web-Services stack, e.g. Metro, it might not be very convenient to enable SOAP message - tracing. In that case, and assuming you application is deployed + tracing. In that case, and assuming your application is deployed on Tomcat, you might want to enable <a href="http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_Filter">RequestDumperFilter</a>. Unfortunately, not only is <code>RequestDumperFilter</code> @@ -56,16 +56,16 @@ incoming request nor the outgoing response. </p> - <p>With help of logback-access and the <a - href="../access.html#teeFilter">TeeFilter</a> you can capture - the full input and output for each request as explained below. + <p>With the help of <a href="../access.html#teeFilter"> + logback-access its TeeFilter</a> you can capture the full input + and output for each request as explained below. </p> - <h3>Capturing</h3> + <h3><a name="capturing" href="#capturing">Capturing</a></h3> - <p>The <code>TeeFilter</code>, as any other servlet filter needs - to be declared in your web-application's <em>web.xml</em> + <p>The <code>TeeFilter</code>, as any other servlet filter, + needs to be declared in your web-application's <em>web.xml</em> file. Here is the decleration to add to your web-application's <em>web.xml</em> file. </p> @@ -97,14 +97,19 @@ <pre class="prettyprint source"><configuration> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> - <layout class="ch.qos.logback.access.PatternLayout"> - <pattern>%fullRequest%n%n%fullResponse</pattern> - </layout> + <encoder> + <pattern><b>%fullRequest</b>%n%n<b>%fullResponse</b></pattern> + </encoder> </appender> <appender-ref ref="STDOUT" /> </configuration></pre> + <p>For the list of conversion words supported by logback-access' + <code>PatternLayout</code> please refer to <a + href="manual/layouts.html#AccessPatternLayout">its documentation</a>. + </p> + <p>Here is the output generated when accessing the <a href="../demo.html">logback-demo</a> application configured as shown above, yields:</p> @@ -141,8 +146,8 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <p> </p> - <h3>Disabling <code>TeeFilter</code> in the production - environment</h3> + <h3><a name="disabling" href="#disabling">Disabling + <code>TeeFilter</code> in the production environment</a></h3> <p>Due to its instrusive nature, <code>TeeFilter</code> can slow down performance. Moreover, altough we have fixed all currently @@ -168,19 +173,84 @@ Set-Cookie: JSESSIONID=bgebt99ce9om;path=/logback-demo <filter-class>ch.qos.logback.access.servlet.TeeFilter</filter-class> <init-param> <b><!-- exclude captures on production systems --></b> - <b><param-name>excludes</param-name></b> - <b><param-value>orion, gemini</param-value></b> + <param-name><b>excludes</b></param-name> + <param-value>orion, gemini</param-value> </init-param> </filter> </pre> - <p>If it is easier, you could also explicitly name the machines - of the integration envrionment in the includes list. + <p>If it is easier to exliclitly name the integration machines, + you could list them in the includes list and omit the excludes + list. </p> - <h3>Filtering captured requests</h3> + <h3><a name="filtering" href="#filtering">Filtering captured + requests</a></h3> - + <p>Let assume that our web-application is deployed in a + cluster. The cluster is located behind a load-balancer which + probes each member of the cluster once or twice a second to + check whether it is alive. Whenever a member becomes unavailable + the load-blancer will immediately (well, after at most one + second) divert traffic from that member. + </p> + + <p>While such a load-balancing strategy will ensure + high-availability of your web-applicaiton, it will also + seriously pollute the access-logs with the contents of each + probe made by the load-balancer. + </p> + + <p>We need to a way to filter-out these probes so that they are + no longer contaminate the log output. However, we need a way to + distinguish probes emanating from the load-balancer from other + requests that we deem desirable. The contents of the requests + can give you clues about possible criteria.</p> + + <p>Here is a sample probe as logged by logback-access:</p> + + <pre class="source"><b>HEAD</b> /myapp/<b>probe</b> HTTP/1.1 +connection: Close +host: 192.168.1.1 + +HTTP/1.1 200 OK +Expires: Thu, 01 Jan 1970 01:00:00 CET +X-Powered-By: Servlet 2.4; +Cache-Control: no-cache +Pragma: No-cache </pre> + + <p>From the above, we can see that the load-blancer probes use + the <a + href="http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4">HTTP + HEAD method</a> instead of the usual GET or POST. We can also + see that the request URI for the probes contains the string + "probe".</p> + + <p>Here is a <em>logback-access.xml</em> configuration file + which will deny any access event which uses the HEAD + method. Note that it is based on Janino.</p> + + <pre class="prettyprint source"><configuration> + <!-- always a good idea to install OnConsoleStatusListener --> + <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> + + <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> + <filter class="ch.qos.logback.core.filter.EvaluatorFilter"> + <!-- in the absence of a class attribute the <evaluator> element + defaults to ch.qos.logback.access.boolex.JaninoEventEvaluator --> + <evaluator> + <expression><b>event.getMethod().equals("HEAD")</b></expression> + </evaluator> + <onMismatch>NEUTRAL</onMismatch> + <onMatch>DENY</onMatch> + </filter> + + <encoder> + <pattern>%fullRequest%n%n%fullResponse</pattern> + </encoder> + </appender> + <appender-ref ref="STDOUT" /> +</configuration> </pre> <script src="../templates/footer.js" type="text/javascript"></script> </div> ----------------------------------------------------------------------- Summary of changes: .../java/chapters/filters/accessEventEvaluator.xml | 29 ++-- .../chapters/filters/accessEventEvaluator2.xml | 42 ++--- logback-site/src/site/pages/access.html | 50 +---- logback-site/src/site/pages/manual/filters.html | 215 +++++++++++++------- .../src/site/pages/recipes/captureHttp.html | 110 ++++++++-- .../images/chapters/filters/countingFilter.png | Bin 0 -> 89406 bytes 6 files changed, 275 insertions(+), 171 deletions(-) create mode 100644 logback-site/src/site/resources/manual/images/chapters/filters/countingFilter.png hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.