[logback-dev] svn commit: r1880 - in logback/trunk/logback-site/src/site/pages: . manual
noreply.ceki at qos.ch
noreply.ceki at qos.ch
Mon Oct 27 20:34:59 CET 2008
Author: ceki
Date: Mon Oct 27 20:34:59 2008
New Revision: 1880
Modified:
logback/trunk/logback-site/src/site/pages/manual/filters.html
logback/trunk/logback-site/src/site/pages/manual/joran.html
logback/trunk/logback-site/src/site/pages/news.html
Log:
- rewording in filters.html
- Added blurb on LBCORE-32
- various updates to news.html
Modified: logback/trunk/logback-site/src/site/pages/manual/filters.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/manual/filters.html (original)
+++ logback/trunk/logback-site/src/site/pages/manual/filters.html Mon Oct 27 20:34:59 2008
@@ -105,10 +105,11 @@
filter.
</p>
- <p>
- The next class is all it takes to implement one's own filter. All it does is accept
- logging events who's message contains the String <em>sample</em>. The filter will give a
- neutral response to any logging event who's message does not contain this String.
+ <p>The next class is all it takes to implement one's own
+ filter. All it does is accept logging events who's message
+ contains the String <em>sample</em>. The filter will give a
+ neutral response to any logging event who's message does not
+ contain this String.
</p>
<em>Example 6.1: Basic custom filter (<a href="../xref/chapter6/SampleFilter.html">logback-examples/src/main/java/chapter6/SampleFilter.java</a>)</em>
@@ -156,17 +157,17 @@
</root>
</configuration></pre></div>
- <p>
- Thanks to Joran, logback's powerful configuration framework, adding
- an option to such a filter is very easy. Just add the corresponding
- getter and setter methods in the class, and you can specify the
- option's value in an xml element, nested within the <em>filter</em> element.
+ <p>Thanks to Joran, logback's powerful configuration framework,
+ adding an option to such a filter is very easy. Just add the
+ corresponding getter and setter methods in the class, and you can
+ specify the option's value in an xml element, nested within the
+ <em>filter</em> element.
</p>
- <p>
- In case you want to implement a filter that provides different behaviour
- depending on the result of its test (say, a filter that would accept or deny
- an event depending on the content of its message), you can extend the
+ <p>In case you want to implement a filter that provides different
+ behaviour depending on the result of its test (say, a filter that
+ would accept or deny an event depending on the content of its
+ message), you can extend the
<a href="../xref/ch/qos/logback/core/filter/AbstractMatcherFilter.html">
<code>AbstractMatcherFilter</code></a> class. It will provide your filter with
two attribute: <em>OnMatch</em> and <em>OnMismatch</em>, that can be configured
@@ -433,32 +434,32 @@
<a name="TurboFilter"></a>
<h3>TurboFilters</h3>
- <p>
- <code>TurboFilter</code> objects all extend the
+ <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.
+ <code>TurboFilter</code></a> abstract class. Like the regular
+ 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>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><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>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 instantiation, nor any other treatement to provide
- their filtering functionnalities. They are much more performant
- than the usual <code>Filter</code> objects.
- </p>
+ <code>LoggingEvent</code> object creation.
+ <code>TurboFilter</code> objects do not require the instantiation
+ of a logging event to filter a logging request. As such, turbo
+ filters are intended for high performance filtering of logging
+ event, even before they are created.
+ </p>
+
<h3>Implementing your own TurboFilter</h3>
@@ -519,21 +520,20 @@
}
</pre></div>
- <p>
- The <code>TurboFilter</code> above accepts events that contain a specific marker.
- If said marker is not found, then the filter passes the responsability to
- the next filter in the chain.
+ <p>The <code>TurboFilter</code> above accepts events that contain
+ a specific marker. If said marker is not found, then the filter
+ passes the responsability to the next filter in the chain.
</p>
- <p>
- To allow more flexibility, the marker that will be tested can be specified
- in the configuration file. Hence the getter and setter methods. We also implemented
- the <code>start()</code> method, to check that the option has been specified during the
- configuration process.
+ <p>To allow more flexibility, the marker that will be tested can
+ be specified in the configuration file. Hence the getter and
+ setter methods. We also implemented the <code>start()</code>
+ method, to check that the option has been specified during the
+ configuration process.
</p>
- <p>
- Here is a sample configuration that makes use of the newly created <code>TurboFilter</code>.
+ <p>Here is a sample configuration that makes use of our newly
+ created <code>TurboFilter</code>.
</p>
<em>Example 6.7: Basic custom <code>TurboFilter</code> configuration (logback-examples/src/main/java/chapter6/sampleTurboFilterConfig.xml)</em>
@@ -556,18 +556,20 @@
</root>
</configuration></pre></div>
- <p>
- Logback classic ships with several <code>TurboFilter</code> classes ready for use.
- 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 associated with the logging request.
+ <p>Logback classic ships with several <code>TurboFilter</code>
+ classes ready for use. 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 whereas <a
+ href="../apidocs/ch/qos/logback/classic/turbo/DynamicThresholdFilter.html"><code>DynamicThresholdFilter</code></a>
+ allows filtering based on MDC key/level thresold associations. 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 associated with the
+ logging request.
</p>
- <p>
- Here is a sample configuration, using both <code>MDCFilter</code> and
- <code>MarkerFilter</code>.
+ <p>Here is a sample configuration, using both
+ <code>MDCFilter</code> and <code>MarkerFilter</code>.
</p>
<em>Example 6.8: <code>MDCFilter</code> and <code>MarkerFilter</code>
Modified: logback/trunk/logback-site/src/site/pages/manual/joran.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/manual/joran.html (original)
+++ logback/trunk/logback-site/src/site/pages/manual/joran.html Mon Oct 27 20:34:59 2008
@@ -328,6 +328,18 @@
printed.
</p>
+ <h3>Specifying the location of the default configuration file as a
+ system property</h3>
+
+ <p>If you wish, you can specify the location of the default
+ configuration file with a system property named
+ <code>logback.configurationFile</code>. The value of the this
+ property can be a URL, a resource on the class path or a path to a
+ file external to the application.
+ </p>
+
+ <p class="source">java <b>-Dlogback.configurationFile=/path/to/config.xml</b> chapter3.MyApp1</p>
+
<h3>Invoking <code>JoranConfigurator</code> directly</h3>
<p>Logback relies on a configuration library called Joran which is
Modified: logback/trunk/logback-site/src/site/pages/news.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/news.html (original)
+++ logback/trunk/logback-site/src/site/pages/news.html Mon Oct 27 20:34:59 2008
@@ -29,7 +29,7 @@
<hr width="80%" align="center" />
- <h3>XXth of October 2008 - Release of version 0.9.10</h3>
+ <h3>27th of October 2008 - Release of version 0.9.10</h3>
<p>In case of errors during initialization, logback-classic now
<em>automatically</em> prints out its internal status. This has been
@@ -82,6 +82,11 @@
directories.
</p>
+ <p>Fixed <a href="http://jira.qos.ch/browse/LBCORE-15">LBCORE-15</a>
+ reported by Klaus Unger and others. DBAppender should now work with
+ Oracle 9, 10g and 11g, regardless of the JDBC driver type used.
+ </p>
+
<p>Fixed issue <a
href="http://jira.qos.ch/browse/LBCORE-17">LBCORE-17</a> reported by
Thorbjørn Ravn Andersen. Logback now relies on Geronimo JMS
@@ -99,7 +104,10 @@
documented.
</p>
- <p><a href="http://jira.qos.ch/browse/LBCORE-32">LBCORE-32</a>
+ <p>The location of the default configuration file can be specified
+ by a system property. This feature was requested in <a
+ href="http://jira.qos.ch/browse/LBCORE-32">LBCORE-32</a> by Ted
+ Graham, Matt Fowles, Ivan Biddles and Ralph Goers.
</p>
<p>Fixed issue <a
@@ -151,11 +159,13 @@
as 0-23 and not as 1-12 as previously.
</p>
- <p><a href="http://jira.qos.ch/browse/LBCLASSIC-53">LBCLASSIC-53</a>
+ <p>Added a new TurboFilter called DynamicThresholdFilter which can
+ filter events depending on MDC values based on a variery of criteria
+ such as company name, product or the end user. This filter was
+ contributed by Ralph Goers in <a
+ href="http://jira.qos.ch/browse/LBCLASSIC-53">LBCLASSIC-53</a>.
</p>
-
-
<hr width="80%" align="center" />
More information about the logback-dev
mailing list