[logback-dev] branch, master, updated. 392672023cda2281b905c62f730cdd3b585aa853

[added by portage for gitosis-gentoo]

The branch, master has been updated
       via  392672023cda2281b905c62f730cdd3b585aa853 (commit)
      from  33dfb1600acd3d5e2c6f98e4f471be8ac3d796e2 (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=392672023cda2281b905c62f730cdd3b585aa853
http://github.com/ceki/logback/commit/392672023cda2281b905c62f730cdd3b585aa853

commit 392672023cda2281b905c62f730cdd3b585aa853
Author: Ceki Gulcu <ceki at qos.ch>
Date:   Wed Oct 28 22:27:35 2009 +0100

    - applied cehjohnson's commit f257e840947c41c6ae5c5ed182e7ccb5c3ffd640
      from October 02, 2009

diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html
index b1e7c31..6d353c3 100644
--- a/logback-site/src/site/pages/manual/architecture.html
+++ b/logback-site/src/site/pages/manual/architecture.html
@@ -44,7 +44,7 @@
     <h2>Logback's architecture</h2>
 
     <p>Logback's basic architecture is sufficiently generic so as to
-    	apply under different circumstances. At present time, logback is
+	apply under different circumstances. At the present time, logback is
     	divided into three modules, Core, Classic and Access.
     </p>
 
@@ -150,7 +150,7 @@ public interface Logger {
 		that is TRACE, 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>
+		more flexible approach exists in the form of <code>Marker</code>
 		objects.
 		</p>
 
@@ -244,7 +244,7 @@ public interface Logger {
 		</table>
 
 		<p>In example 2 above, all loggers have an assigned level value.
-		Level inheritence does not come into play.
+		Level inheritance does not come into play.
 		</p>
 
 		<em>Example 3</em>
@@ -358,7 +358,7 @@ public interface Logger {
 		</p>
 				
 		<p>In a more graphic way, here is how the selection rule works. In
-		the following table, the vertical header shows the the level of
+		the following table, the vertical header shows the level of
 		the logging request, designated by <em>p</em>, while the
 		horizontal header shows effective level of the logger, designated
 		by <em>q</em>. The intersection of the rows (level request) and
@@ -541,8 +541,8 @@ Logger y = LoggerFactory.getLogger("wombat");</pre>
 
 			<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
+			will be directed to all the appenders in <em>L</em> and its
+			ancestors up to and including <em>P</em> but not the appenders in
 			any of the ancestors of <em>P</em>.
 			</p>
 
@@ -727,7 +727,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
 
   
   <a name="UnderTheHood"></a>
-  <h3>A peak under the hood</h3>
+  <h3>A peek under the hood</h3>
 
   <p>After we have introduced the essential logback components, we are
   now ready to describe the steps that the logback framework takes
@@ -762,7 +762,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
 
   <h4>3. Create a <code>LoggingEvent</code> object</h4>
 
-  <p>If the request survivedy the previous filters, logback will
+  <p>If the request survived the previous filters, logback will
   create a <code>ch.qos.logback.classic.LoggingEvent</code> object
   containing all the relevant parameters of the request, such as the
   logger of the request, the request level, the message itself, the
@@ -854,7 +854,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
 
   <p>The cost of parameter construction can be quite high and depends
   on the size of the parameters involved. To avoid the cost of
-  parameter construction you can take advantage of SLF4J's parametrized
+  parameter construction you can take advantage of SLF4J's parameterized
   logging:
   </p>
 
@@ -872,9 +872,9 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
   </p>
 
   <p> Please notice that, despite the performance points that we just
-  discussed, inserting logging statements in tight-loops or very
+  discussed, inserting logging statements in tight loops or very
   frequently invoked code is a lose-lose proposal and is likely to
-  result in degraded performance. Logging in tight-loops slow down
+  result in degraded performance. Logging in tight loops slow down
   your application even if logging is turned off, and if logging is
   turned on, they will generate massive (and hence useless) output.
   </p>
diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html
index 3d7a2d0..f8b0581 100644
--- a/logback-site/src/site/pages/manual/introduction.html
+++ b/logback-site/src/site/pages/manual/introduction.html
@@ -123,12 +123,12 @@ public class HelloWorld1 {
 
 
     <p>You can launch the first
-    sample application, <em>chapter1.HelloWord1</em> with the command:
+    sample application, <em>chapter1.HelloWorld1</em> with the command:
     </p>
     <div class="source"><pre>java chapter1.HelloWorld1</pre></div>
 
     <p>Launching the <code>HelloWorld1</code> application will output
-    a single line on the console. By virtue of to logback's default
+    a single line on the console. By virtue of logback's default
     configuration policy, when no default configuration file is found,
     logback will add a <code>ConsoleAppender</code> to the root
     logger.
@@ -191,9 +191,9 @@ public class HelloWorld2 {
 
   <p>The previous examples are rather simple. Actual logging in a
   larger application would not be that different. The general pattern
-  for logging statements would not change. nly the configuration
-  process would be different since However, you would probably want to
-  customize or configure logback for according to your needs. Logback
+  for logging statements would not change. Only the configuration
+  process would be different. However, you would probably want to
+  customize or configure logback according to your needs. Logback
   configuration will be covered in subsequent chapters.
   </p>
 
@@ -216,7 +216,7 @@ public class HelloWorld2 {
     <code>Logger</code> instance by invoking the
     <code>org.slf4j.LoggerFactory</code> class'
     <code>getLogger()</code> method, passing the current class name
-    or the class itself as parameter.</li>
+    or the class itself as a parameter.</li>
     
     <li>Use this logger instance by invoking its printing methods,
     namely the debug(), info(), warn() and error(). This will

-----------------------------------------------------------------------

Summary of changes:
 .../src/site/pages/manual/architecture.html        |   22 ++++++++++----------
 .../src/site/pages/manual/introduction.html        |   12 +++++-----
 2 files changed, 17 insertions(+), 17 deletions(-)


hooks/post-receive
-- 
Logback: the generic, reliable, fast and flexible logging framework.