[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 &gt;= 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&nbsp;&gt;=&nbsp;q</em>.
 			</p>
 		</div>
 
-		<p>
-			This rule is at the heart of logback. It assumes
-			that levels are ordered as follows: 
-			<code>DEBUG &lt; INFO &lt; WARN &lt; ERROR&lt; OFF</code>.
+		<p>This rule is at the heart of logback. It assumes that levels
+		are ordered as follows: <code>DEBUG &lt; INFO &lt; WARN &lt;
+		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