Index: filters.html
===================================================================
--- filters.html	(revision 1701)
+++ filters.html	(working copy)
@@ -54,7 +54,7 @@
 		<h2>Logback Classic</h2>
 		
 		<a name="Filter"></a>
-		<p><code>Filter</code> objects all implement the 
+		<p><code>Filter</code> objects all extend the 
 		<a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> 
 		abstract class. The <code>decide(Object event)</code> method is passed a
 		newly created <code>LoggingEvent</code> object.
@@ -62,7 +62,7 @@
 		
 		<h3>Filter chains</h3>
 		<p>
-			This abstract class assumes that filters be organized in a linear chain. 
+			This abstract class assumes that filters can 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.
@@ -73,7 +73,8 @@
     <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 
+	<a href="../xref/ch/qos/logback/core/spi/FilterReply.html"><code>FilterReply</code></a>
+	enumeration values. Either <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>, 
@@ -84,7 +85,7 @@
     </p>
     
     <p>
-    	In logback-classic, <code>Filter</code> objects can only be added to <code>Appender</code>
+    	In logback-classic <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 MDC, 
     	the time of day or any other part of the logging event.
@@ -169,7 +170,7 @@
 		<h3>Logback Filters</h3>
 		
 		<p>
-			As the moment, there are two filters that ship with logback.
+			At the moment, there are two filters that ship with logback.
 			<a href="../xref/ch/qos/logback/classic/LevelFilter.html">
 			<code>LevelFilter</code></a> provides event filtering based on a <code>Level</code> value. 
 			It the event's level is equal to the configured level, the filter accepts of denies
@@ -230,29 +231,33 @@
 		<h3>Evaluator Filters</h3>
 		    
 		<p>
-			A special category of filters ships with logback. The
+			A special category of filters is implemented by the
     	<a href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html">
-    	<code>EvaluatorFilter</code></a> objects use an 
+    	<code>EvaluatorFilter</code></a> class. These filters use 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
+    	<code>EventEvaluator</code></a> object
+    	to decide wether to accept or deny a request. This allows unprecedented
     	flexibility in the way that you can affect the logging event's filtering.
     </p>
     
     <p>
-			Creating a customized filter that makes use of <code>EventEvaluator</code> objects
-			works the same way as seen previously, except that one must extend the 
-			<code>EvaluatorFilter</code> class, instead of the <code>Filter</code>
+			Creating a customized filter that makes use of an
+			<code>EventEvaluator</code> object
+			works the same way as shown previously, except that one must implement the 
+			<code>EvaluatorFilter</code> interface instead of
+			extending <code>Filter</code>
 			or <code>AbstractMatcherFilter</code> classes.
 		</p>
     
     <a name="EventEvaluator"></a>
-    <h3>Event Evaluators</h3>
-    
+    <h3>Evaluator Filters With Literal Java Expressions</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.
+    	Events evaluators allow the user to provide leteral java expressions
+	directly in the configuration file. This is done using
+	<code>evaluator</code> configuration element.
+	The expression can access logging event components by name
+	and should evaluate either to <code>true</code> or <code>false</code>.
     </p>
     
     <p>
@@ -450,7 +455,7 @@
 		<h3>TurboFilters</h3>
     
     <p>
-    	<code>TurboFilter</code> objects all extend the 
+    	<code>TurboFilter</code> objects 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.
@@ -471,7 +476,7 @@
    	<p>
    		More importantly, 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 logging event instanciation, nor any other treatement to provide their 
+   		no logging event instantiation, nor any other treatement to provide their 
    		filtering functionnalities. They are much more performant than the usual
    		<code>Filter</code> objects.
    	</p>
@@ -671,25 +676,26 @@
     	in the same way as their classic counterpart. They handle access' implementation
     	of logging events: <code>AccessEvent</code>. 
     	Thus, a customized filter
-    	for logback access is follows strictly the same rules than one for the 
+    	for logback access follows strictly the same rules than one for the 
     	classic module, except for the event implemenation recieved as a parameter.
     	On the other hand,
-    	<code>TurboFilter</code> objects are not available to the access module.
+    	<code>TurboFilters</code> are not supported by the access module.
     </p>
     
     <h3>Filters</h3>
     
     <p>
-    	<code>EvaluatorFilter</code> objects, with their expressions, are available to
+	<code>EvaluatorFilter</code> objects with java expressions supplied in
+	in <code>evaluator</code> configuration elements are supported by
     	the access module. However, the variables that one can use to build an expression
     	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
+    	<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 displayed:
+    	Here is a sample configuration that will ensure that any 404 error will be logged:
     </p>
    	
 <em>Example 6.9: Access Evaluator (logback-examples/src/main/java/chapter6/accessEventEvaluator.xml)</em>
@@ -711,12 +717,14 @@
     &lt;/layout>
   &lt;/appender>
 
+  &lt;root>
   &lt;appender-ref ref="STDOUT" />
+  &lt;/root>
 &lt;/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
+			We might imagine a slightly more complex use of filters to ensure logging of all 404 errors
+			except those returned on access to CSS resources. Here is what such a configuration
 			would look like:
 		</p>	
 
@@ -746,7 +754,9 @@
     &lt;/layout>
   &lt;/appender>
 
+  &lt;root>
   &lt;appender-ref ref="STDOUT" />
+  &lt;/root>
 &lt;/configuration></pre></div>	
 		
 	</div>
