[logback-dev] svn commit: r1752 - in logback/trunk/logback-site/src/site/pages: . css manual templates
noreply.ceki at qos.ch
noreply.ceki at qos.ch
Sat Aug 9 23:42:10 CEST 2008
Author: ceki
Date: Sat Aug 9 23:42:09 2008
New Revision: 1752
Modified:
logback/trunk/logback-site/src/site/pages/css/site.css
logback/trunk/logback-site/src/site/pages/documentation.html
logback/trunk/logback-site/src/site/pages/download.html
logback/trunk/logback-site/src/site/pages/manual/architecture.html
logback/trunk/logback-site/src/site/pages/templates/right.js
Log:
- improving the docs
Modified: logback/trunk/logback-site/src/site/pages/css/site.css
==============================================================================
--- logback/trunk/logback-site/src/site/pages/css/site.css (original)
+++ logback/trunk/logback-site/src/site/pages/css/site.css Sat Aug 9 23:42:09 2008
@@ -226,6 +226,10 @@
background-color: #eee;
}
+table.bodyTable tr.alt {
+ background-color: #eee;
+}
+
.author {
text-align: left;
font-weight: bold;
Modified: logback/trunk/logback-site/src/site/pages/documentation.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/documentation.html (original)
+++ logback/trunk/logback-site/src/site/pages/documentation.html Sat Aug 9 23:42:09 2008
@@ -38,11 +38,7 @@
<li>
<a href="dependencies.html">Dependencies per module</a>
</li>
-
-
- <li>
- <a href="bridge.html">How to use the log4j bridge</a>
- </li>
+
<li>
<a href="jmxConfig.html">How to use the logback JMX Configurator</a>
</li>
Modified: logback/trunk/logback-site/src/site/pages/download.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/download.html (original)
+++ logback/trunk/logback-site/src/site/pages/download.html Sat Aug 9 23:42:09 2008
@@ -84,7 +84,7 @@
</dt>
<dd>
- <p>Lilith is a Logging- and AccessEvent viewer for LOGBack.
+ <p>Lilith is a Logging- and AccessEvent viewer for logback.
</p>
</dd>
Modified: logback/trunk/logback-site/src/site/pages/manual/architecture.html
==============================================================================
--- logback/trunk/logback-site/src/site/pages/manual/architecture.html (original)
+++ logback/trunk/logback-site/src/site/pages/manual/architecture.html Sat Aug 9 23:42:09 2008
@@ -46,35 +46,35 @@
</p>
<p>The <em>core</em> module lays the groundwork for the other two
- modules. The <em>classic</em> module extends <em>core</em>. The
- classic module corresponds to a significantly improved version
- of log4j. Logback-classic natively implements the <a
- href="http://www.slf4j.org">SLF4J API</a> so that you can
- readily switch back and forth between logback and other logging
- systems such as log4j or JDK14 Logging. The third module called
- <em>access</em> integrates with Servlet containers to provide
- HTTP-access log functionality. The access module will be covered
- in a <a href="../access.html">separate document</a>.
+ modules. The <em>classic</em> module extends <em>core</em>. The
+ classic module corresponds to a significantly improved version of
+ log4j. Logback-classic natively implements the <a
+ href="http://www.slf4j.org">SLF4J API</a> so that you can readily
+ switch back and forth between logback and other logging systems
+ such as log4j or java.util.logging (JUL) introduced in JDK
+ 1.4. The third module called <em>access</em> integrates with
+ Servlet containers to provide HTTP-access log functionality. The
+ access module will be covered in a <a
+ href="../access.html">separate document</a>.
</p>
- <p>
- In the reminder of this document, we will write "logback" to refer to the
- logback classic module.
+
+ <p>In the reminder of this document, we will write "logback" to
+ refer to the logback-classic module.
</p>
<h2>Logger, Appenders and Layouts</h2>
- <p>
- Logback has three main types: <code>Logger</code>,
- <code>Appender</code> and <code>Layout</code>. These three types of components work
- together to enable developers to log messages according to
- message type and level, and to control at runtime how these
- messages are formatted and where they are reported.
+ <p>Logback is built upon three main classes: <code>Logger</code>,
+ <code>Appender</code> and <code>Layout</code>. These three types
+ of components work together to enable developers to log messages
+ according to message type and level, and to control at runtime how
+ these messages are formatted and where they are reported.
</p>
- <p>
- The Logger class is part of the classic module. On the other
- hand, the <code>Appender</code> and <code>Layout</code> interfaces
- are part of the core module. For the sake of genericity,
- logback-core has no notion of loggers.
+
+ <p>The <code>Logger</code> class is part of the logback-classic
+ module. On the other hand, the <code>Appender</code> and
+ <code>Layout</code> interfaces are part of logback-core. As a
+ general-purpose module, logback-core has no notion of loggers.
</p>
<a name="LoggerContext"></a>
@@ -85,8 +85,8 @@
certain log statements while allowing others to print
unhindered. This capability assumes that the logging space, that
is, the space of all possible logging statements, is categorized
- according to some developer-chosen criteria. In logback, this
- categorization is an inherent part of loggers.
+ according to some developer-chosen criteria. In logback-classic,
+ this categorization is an inherent part of loggers.
</p>
<p>
@@ -140,27 +140,24 @@
public void fatal(String message);
}</pre></div>
- <p>
- Loggers may be assigned levels. The set of possible levels, that
- is DEBUG, INFO, WARN and ERROR are defined in the
- <code>ch.qos.logback.classic.Level</code> class. Note that in
- logback, the level class is final and cannot be derived, as a
- much more flexible approach exist in the form of Marker objects.
+ <p>Loggers may be assigned levels. The set of possible levels,
+ that is DEBUG, INFO, WARN and ERROR are defined in the
+ <code>ch.qos.logback.classic.Level</code> class. Note that in
+ logback, the level class is final and cannot be derived, as a much
+ more flexible approach exist in the form of <code>Marker</code>
+ objects.
</p>
- <p>
- If a given logger is not assigned a level, then it inherits
- one from its closest ancestor with an assigned level. More
- formally:
+ <p>If a given logger is not assigned a level, then it inherits one
+ from its closest ancestor with an assigned level. More formally:
</p>
<div class="definition">
<div class="deftitle">Level Inheritance</div>
- <p>
- The effective level for a given logger <em>L</em>, is equal to
- the first non-null level in its hierarchy, starting at
- <em>L</em> itself and proceeding upwards in the hierarchy
- towards the root logger.
+ <p>The effective level for a given logger <em>L</em>, is equal
+ to the first non-null level in its hierarchy, starting at
+ <em>L</em> itself and proceeding upwards in the hierarchy
+ towards the root logger.
</p>
</div>
@@ -178,34 +175,27 @@
<em>Example 1</em>
<table class="bodyTable">
<tr>
- <th>
- Logger name
- </th>
- <th>
- Assigned level
- </th>
-
- <th>
- Effective level
- </th>
+ <th>Logger name</th>
+ <th>Assigned level</th>
+ <th>Effective level</th>
</tr>
- <tr class="a">
+ <tr class="alt">
<td>root</td>
<td>DEBUG</td>
<td>DEBUG</td>
</tr>
- <tr class="b">
+ <tr>
<td>X</td>
<td>none</td>
<td>DEBUG</td>
</tr>
- <tr class="a">
+ <tr class="alt">
<td>X.Y</td>
<td>none</td>
<td>DEBUG</td>
</tr>
- <tr class="b">
+ <tr>
<td>X.Y.Z</td>
<td>none</td>
<td>DEBUG</td>
@@ -218,20 +208,13 @@
</p>
<em>Example 2</em>
- <table>
+ <table class="bodyTable">
<tr>
- <th>
- Logger name
- </th>
- <th>
- Assigned level
- </th>
-
- <th>
- Effective level
- </th>
+ <th>Logger name</th>
+ <th>Assigned level</th>
+ <th>Effective level</th>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>root</td>
<td>ERROR</td>
<td>ERROR</td>
@@ -242,7 +225,7 @@
<td>INFO</td>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>X.Y</td>
<td>DEBUG</td>
<td>DEBUG</td>
@@ -259,19 +242,13 @@
</p>
<em>Example 3</em>
- <table>
+ <table class="bodyTable">
<tr>
- <th>
- Logger name
- </th>
- <th>
- Assigned level
- </th>
- <th>
- Effective level
- </th>
+ <th>Logger name</th>
+ <th>Assigned level</th>
+ <th>Effective level</th>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>root</td>
<td>DEBUG</td>
<td>DEBUG</td>
@@ -282,7 +259,7 @@
<td>INFO</td>
<td>INFO</td>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>X.Y</td>
<td>none</td>
<td>INFO</td>
@@ -293,28 +270,23 @@
<td>ERROR</td>
</tr>
</table>
- <p>
- In example 3 above, the loggers <code>root</code>, <code>X</code>
- and <code>X.Y.Z</code> are assigned the levels <code>DEBUG</code>,
- <code>INFO</code> and <code>ERROR</code>
- respectively. Logger <code>X.Y</code>
- inherits its level value from its parent <code>X</code>.
+
+ <p>In example 3 above, the loggers <code>root</code>,
+ <code>X</code> and <code>X.Y.Z</code> are assigned the levels
+ <code>DEBUG</code>, <code>INFO</code> and <code>ERROR</code>
+ respectively. Logger <code>X.Y</code> inherits its level value
+ from its parent <code>X</code>.
</p>
+
<em>Example 4</em>
- <table>
+ <table class="bodyTable">
<tr>
- <th>
- Logger name
- </th>
- <th>
- Assigned level
- </th>
- <th>
- Effective level
- </th>
+ <th>Logger name</th>
+ <th>Assigned level</th>
+ <th>Effective level</th>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>root</td>
<td>DEBUG</td>
<td>DEBUG</td>
@@ -325,7 +297,7 @@
<td>INFO</td>
<td>INFO</td>
</tr>
- <tr align="left">
+ <tr class="alt" align="left">
<td>X.Y</td>
<td>none</td>
<td>INFO</td>
@@ -346,6 +318,7 @@
</p>
<a name="PrintintMethods"></a>
+ <a name="basic_selection"></a>
<h3>Printing methods</h3>
<p>By definition, the printing method determines the level of a
@@ -354,25 +327,27 @@
logging statement of level INFO.
</p>
+
<p>A logging request is said to be <em>enabled</em> if its level
- is higher than or equal to the level of its logger. Otherwise, the
- request is said to be <em>disabled</em>. A logger without an
- assigned level will inherit one from the context. This rule is
- summarized below.
+ is higher than or equal to the effective level of its
+ logger. Otherwise, the request is said to be <em>disabled</em>. As
+ described previously, a logger without an assigned level will
+ inherit one from its nearest ancestor. This rule is summarized
+ below.
</p>
+
<div class="definition">
<div class="deftitle">Basic Selection Rule</div>
- <p>A log request of level <em>p</em> in a logger with an
- effective level <em>q</em>, is enabled if <em>p >= q</em>.
+ <p>A log request of level <em>p</em> issued with a logger having
+ an effective level <em>q</em>, is enabled if <em>p >= q</em>.
</p>
</div>
- <p>
- This rule is at the heart of logback. It assumes
- that levels are ordered as follows:
- <code>DEBUG < INFO < WARN < ERROR< OFF</code>.
+ <p>This rule is at the heart of logback. It assumes that levels
+ are ordered as follows: <code>DEBUG < INFO < WARN <
+ ERROR</code>.
</p>
<p>In a more graphic way, here is how the selection rule works. In
@@ -427,7 +402,7 @@
<p>Here is an example of the basic selection rule.</p>
- <div class="source"><pre>// get a logger instance named "com.foo", with an <span class="blue">INFO</span> level.
+ <div class="source"><pre>// get a logger instance named "com.foo"
Logger logger = LoggerFactory.getLogger("com.foo");
//set its Level to <span class="blue">INFO</span>
logger.setLevel(Level. <span class="blue">INFO</span>);
@@ -465,34 +440,28 @@
<em>exactly</em> the same logger object.
</p>
- <p>
- Thus, it is possible to configure a logger and then to
- retrieve the same instance somewhere else in the code
- without passing around references. In fundamental
- contradiction to biological parenthood, where parents always
- preceed their children, logback loggers can be
- created and configured in any order. In particular, a
- "parent" logger will find and link to its descendants even
- if it is instantiated after them.
- </p>
- <p>
- Configuration of the logback environment is typically done
- at application initialization. The preferred way is by
- reading a configuration file. This approach will be
- discussed shortly.
- </p>
- <p>
- Logback makes it easy to name loggers by <em>software
- component</em>. This can be accomplished by instantiating a
- logger in each class, with the logger name equal to the fully
- qualified name of the class. This is a useful and
- straightforward method of defining loggers. As the log output
- bears the name of the generating logger, this naming strategy
- makes it easy to identify the origin of a log message. However,
- this is only one possible, albeit common, strategy for naming
- loggers. Logback does not restrict the possible set of
- loggers. As a developer, you are free to name loggers as you
- wish.
+ <p>Thus, it is possible to configure a logger and then to retrieve
+ the same instance somewhere else in the code without passing
+ around references. In fundamental contradiction to biological
+ parenthood, where parents always preceed their children, logback
+ loggers can be created and configured in any order. In particular,
+ a "parent" logger will find and link to its descendants even if it
+ is instantiated after them.
+ </p>
+ <p>Configuration of the logback environment is typically done at
+ application initialization. The preferred way is by reading a
+ configuration file. This approach will be discussed shortly.
+ </p>
+ <p>Logback makes it easy to name loggers by <em>software
+ component</em>. This can be accomplished by instantiating a
+ logger in each class, with the logger name equal to the fully
+ qualified name of the class. This is a useful and straightforward
+ method of defining loggers. As the log output bears the name of
+ the generating logger, this naming strategy makes it easy to
+ identify the origin of a log message. However, this is only one
+ possible, albeit common, strategy for naming loggers. Logback does
+ not restrict the possible set of loggers. As a developer, you are
+ free to name loggers as you wish.
</p>
<p>Nevertheless, naming loggers after the class where they are
@@ -502,62 +471,54 @@
<a name="AppendersAndLayouts"></a>
<h3>Appenders and Layouts</h3>
- <p>
- The ability to selectively enable or disable logging requests
- based on their logger is only part of the picture. Logback
- allows logging requests to print to multiple destinations. In
- logback speak, an output destination is called an
- appender. Currently, appenders exist for the console, files,
- remote socket servers, to MySQL, PostgreSQL, Oracle and other
- databases, JMS, and remote UNIX Syslog daemons.
+ <p>The ability to selectively enable or disable logging requests
+ based on their logger is only part of the picture. Logback allows
+ logging requests to print to multiple destinations. In logback
+ speak, an output destination is called an appender. Currently,
+ appenders exist for the console, files, remote socket servers, to
+ MySQL, PostgreSQL, Oracle and other databases, JMS, and remote
+ UNIX Syslog daemons.
<!--It is also possible to log asynchronously. -->
</p>
<p>More than one appender can be attached to a logger.</p>
- <p> The <code><a href="../apidocs/ch/qos/logback/classic/Logger.html#addAppender(ch.qos.logback.core.Appender)">addAppender</a></code> method adds an appender to a
- given logger. Each enabled logging request for a given logger
- will be forwarded to all the appenders in that logger as well as
- the appenders higher in the hierarchy. In other words, appenders are
- inherited additively from the logger hierarchy. For example, if a
- console appender is added to the root logger, then all enabled
- logging requests will at least print on the console. If in
- addition a file appender is added to a logger, say <em>L</em>,
- then enabled logging requests for <em>L</em> and <em>L</em>'s
- children will print on a file <em>and</em> on the console. It is
- possible to override this default behavior so that appender
- accumulation is no longer additive by setting the additivity flag
- of a logger to false.
+ <p>The <code><a
+ href="../apidocs/ch/qos/logback/classic/Logger.html#addAppender(ch.qos.logback.core.Appender)">addAppender</a></code>
+ method adds an appender to a given logger. Each enabled logging
+ request for a given logger will be forwarded to all the appenders
+ in that logger as well as the appenders higher in the
+ hierarchy. In other words, appenders are inherited additively from
+ the logger hierarchy. For example, if a console appender is added
+ to the root logger, then all enabled logging requests will at
+ least print on the console. If in addition a file appender is
+ added to a logger, say <em>L</em>, then enabled logging requests
+ for <em>L</em> and <em>L</em>'s children will print on a file
+ <em>and</em> on the console. It is possible to override this
+ default behavior so that appender accumulation is no longer
+ additive by setting the additivity flag of a logger to false.
</p>
- <p>
- The rules governing appender additivity are summarized
- below.
+ <p>The rules governing appender additivity are summarized below.
</p>
<div class="definition">
<div class="deftitle">Appender Additivity</div>
- <p>
- The output of a log statement of logger <em>L</em>
- will go to all the appenders in <em>L</em>
- and its ancestors. This is the meaning of the term
- "appender additivity".
+ <p>The output of a log statement of logger <em>L</em> will go to
+ all the appenders in <em>L</em> and its ancestors. This is the
+ meaning of the term "appender additivity".
</p>
- <p>
- However, if an ancestor of logger <em>L</em>, say
- <em>P</em>, has the additivity flag set to false, then
- <em>L</em>'s output will be directed to all the appenders in
- <em>L</em> and it's ancestors upto and including
- <em>P</em> but not the appenders in any of the ancestors of
- <em>P</em>.
+ <p>However, if an ancestor of logger <em>L</em>, say <em>P</em>,
+ has the additivity flag set to false, then <em>L</em>'s output
+ will be directed to all the appenders in <em>L</em> and it's
+ ancestors upto and including <em>P</em> but not the appenders in
+ any of the ancestors of <em>P</em>.
</p>
- <p>
- Loggers have their additivity flag set to true by
- default.
+ <p>Loggers have their additivity flag set to true by default.
</p>
</div>
@@ -581,7 +542,7 @@
hiearchy, the additivity flag does not apply to it.
</td>
</tr>
- <tr>
+ <tr class="alt">
<td>x</td>
<td>A-x1, A-x2</td>
<td>true</td>
@@ -595,7 +556,7 @@
<td>A1, A-x1, A-x2</td>
<td>Appenders of "x" and of root.</td>
</tr>
- <tr>
+ <tr class="alt">
<td>x.y.z</td>
<td>A-xyz1</td>
<td>true</td>
@@ -613,7 +574,7 @@
<code>false</code>. Only appender A-sec will be used.
</td>
</tr>
- <tr>
+ <tr class="alt">
<td>security.access</td>
<td>none</td>
<td>true</td>
@@ -627,65 +588,55 @@
</table>
- <p>
- More often than not, users wish to customize not only the
- output destination but also the output format. This is
- accomplished by associating a <em>layout</em>
- with an appender. The layout is responsible for formatting
- the logging request according to the user's wishes, whereas
- an appender takes care of sending the formatted output to
- its destination. The <code>PatternLayout</code>, part of the standard
- logback distribution, lets the user specify the output
- format according to conversion patterns similar to the C
- language <code>printf</code>
- function.
+ <p>More often than not, users wish to customize not only the
+ output destination but also the output format. This is
+ accomplished by associating a <em>layout</em> with an
+ appender. The layout is responsible for formatting the logging
+ request according to the user's wishes, whereas an appender takes
+ care of sending the formatted output to its destination. The
+ <code>PatternLayout</code>, part of the standard logback
+ distribution, lets the user specify the output format according to
+ conversion patterns similar to the C language <code>printf</code>
+ function.
</p>
- <p>
- For example, the PatternLayout with the conversion pattern
- "%-4relative [%thread] %-5level %logger{32} - %msg%n" will output something akin to:
+ <p>For example, the PatternLayout with the conversion pattern
+ "%-4relative [%thread] %-5level %logger{32} - %msg%n" will output
+ something akin to:
</p>
<div class="source"><pre>176 [main] DEBUG chapter2.HelloWorld2 - Hello world.</pre></div>
- <p>
- The first field is the number of milliseconds elapsed since
- the start of the program. The second field is the thread
- making the log request. The third field is the level of the
- log request. The fourth field is the name of the logger
- associated with the log request. The text after the '-' is
- the message of the request.
+ <p>The first field is the number of milliseconds elapsed since the
+ start of the program. The second field is the thread making the
+ log request. The third field is the level of the log request. The
+ fourth field is the name of the logger associated with the log
+ request. The text after the '-' is the message of the request.
</p>
<a name="ParametrizedLogging"></a>
<h3>Parameterized logging</h3>
- <p>
- Given that loggers in logback-classic implement the <a
- href="http://www.slf4j.org/api/org/slf4j/Logger.html">SLF4J's
- Logger interface</a>, certain printing methods admit more than
- one parameter. These printing method variants are mainly
- intended to improve performance while minimizing the impact on
- the readability of the code.
+ <p>Given that loggers in logback-classic implement the <a
+ href="http://www.slf4j.org/api/org/slf4j/Logger.html">SLF4J's
+ Logger interface</a>, certain printing methods admit more than one
+ parameter. These printing method variants are mainly intended to
+ improve performance while minimizing the impact on the readability
+ of the code.
</p>
- <p>
- For some Logger <code>logger</code>, writing,
- </p>
+ <p>For some Logger <code>logger</code>, writing,</p>
<div class="source"><pre>logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));</pre></div>
- <p>
- incurs the cost of constructing the message parameter, that
- is converting both integer <code>i</code> and <code>entry[i]</code>
- to a String, and concatenating intermediate strings. This,
- regardless of whether the message will be logged or not.
+ <p>incurs the cost of constructing the message parameter, that is
+ converting both integer <code>i</code> and <code>entry[i]</code>
+ to a String, and concatenating intermediate strings. This,
+ regardless of whether the message will be logged or not.
</p>
- <p>
- One possible way to avoid the cost of parameter construction
- is by surrounding the log statement with a test. Here is an
- example.
+ <p>One possible way to avoid the cost of parameter construction is
+ by surrounding the log statement with a test. Here is an example.
</p>
<div class="source"><pre>if(logger.isDebugEnabled()) {
@@ -693,55 +644,46 @@
}</pre></div>
- <p>
- This way you will not incur the cost of parameter
- construction if debugging is disabled for <code>logger</code>.
- On the other hand, if the logger is enabled for the DEBUG
- level, you will incur the cost of evaluating whether the
- logger is enabled or not, twice: once in <code>debugEnabled</code>
- and once in <code>debug</code>.
- This is an insignificant overhead because evaluating a
- logger takes less than 1% of the time it takes to actually
- log a request.
+ <p>This way you will not incur the cost of parameter construction
+ if debugging is disabled for <code>logger</code>. On the other
+ hand, if the logger is enabled for the DEBUG level, you will incur
+ the cost of evaluating whether the logger is enabled or not,
+ twice: once in <code>debugEnabled</code> and once in
+ <code>debug</code>. This is an insignificant overhead because
+ evaluating a logger takes less than 1% of the time it takes to
+ actually log a request.
</p>
-
-
<h4>Better alternative</h4>
- <p>
- There exists a convenient alternative based on message
- formats. Assuming <code>entry</code> is an object, you can write:
+ <p>There exists a convenient alternative based on message
+ formats. Assuming <code>entry</code> is an object, you can write:
</p>
<div class="source"><pre>Object entry = new SomeObject();
logger.debug("The entry is {}.", entry);</pre></div>
- <p>
- After evaluting whether to log or not, and only if the decision
- is positive, will the logger implementation format the message
- and replace the '{}' pair with the string value of
- <code>entry</code>. In other words, this form does not incur
- the cost of parameter construction in case the log statement is
- disabled.
+ <p>After evaluting whether to log or not, and only if the decision
+ is positive, will the logger implementation format the message and
+ replace the '{}' pair with the string value of <code>entry</code>.
+ In other words, this form does not incur the cost of parameter
+ construction in case the log statement is disabled.
</p>
- <p>
- The following two lines will yield the exact same output.
- However, in case of a <em>disabled</em>
- logging statement, the second variant will outperform the first variant by a
- factor of at least 30.
+ <p>The following two lines will yield the exact same output.
+ However, in case of a <em>disabled</em> logging statement, the
+ second variant will outperform the first variant by a factor of at
+ least 30.
</p>
<div class="source"><pre>logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);</pre></div>
- <p>
- A two argument variant is also availalble. For example, you
- can write:
+ <p>A two argument variant is also availalble. For example, you can
+ write:
</p>
<div class="source"><pre>logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);</pre></div>
@@ -781,7 +723,8 @@
to step 3.
</p>
- <h4>2. Apply the Logger level filter</h4>
+ <h4>2. Apply the <a href="#basic_selection">basic selection
+ rule</a></h4>
<p>At this step, logback compares the effective level of the logger
with the level of the request. If the logging request is disabled
Modified: logback/trunk/logback-site/src/site/pages/templates/right.js
==============================================================================
--- logback/trunk/logback-site/src/site/pages/templates/right.js (original)
+++ logback/trunk/logback-site/src/site/pages/templates/right.js Sat Aug 9 23:42:09 2008
@@ -1,13 +1,10 @@
-
//document.write('<p class="menu"><a href="'+prefix+'10reasons.ppt">10 reasons for migrating</a>')
document.write('<p class="menu_header">New and noteworthy</p>')
-document.write('<p class="menu"><a href="http://wizardforge.org/pc?action=showVersion&id=72">Configuration Wizard</a>')
-
-http://wizardforge.org/pc?action=showVersion&id=72
+document.write('<p class="menu"><a href="http://stubbisms.wordpress.com/2008/07/15/some-serious-logging-niceness-logback-with-eclipse-plugin/">Logging niceness</a>')
-document.write('<p class="menu"><a href="http://www.javadonkey.com/blog/log4j-isdebugenabled-logback/">isDebugEnabled()</a>')
+document.write('<p class="menu"><a href="http://wizardforge.org/pc?action=showVersion&id=72">Configuration Wizard</a>')
document.write('<p class="menu"><a href="http://xhab.blogspot.com/2007/03/new-logging-experience.html">A new logging experience!</a>')
More information about the logback-dev
mailing list