[logback-dev] [GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.24-19-gb100fbf

added by portage for gitosis-gentoo git-noreply at pixie.qos.ch
Thu Sep 30 21:59:23 CEST 2010


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Logback: the generic, reliable, fast and flexible logging framework.".

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

commit b100fbfa7db3cd43d4551bd70bb523a5c7543311
Author: Ceki Gulcu <ceki at qos.ch>
Date:   Thu Sep 30 21:58:31 2010 +0200

    - Many editorial fixes submitted by Dan Lantz.

diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html
index 6196232..fe45f69 100644
--- a/logback-site/src/site/pages/manual/appenders.html
+++ b/logback-site/src/site/pages/manual/appenders.html
@@ -65,7 +65,7 @@ public interface Appender&lt;E> extends LifeCycle, ContextAware, FilterAttachabl
 }</pre>
 
 	<p>Most of the methods in the <code>Appender</code> interface are
-	made of setter and getter methods. A notable exception is the
+	setters and getters. A notable exception is the
 	<code>doAppend()</code> method taking an object instance of type
 	<em>E</em> as its only parameter. The actual type of <em>E</em>
 	would vary depending on the logback module. Within the
@@ -300,8 +300,8 @@ public interface Appender&lt;E> extends LifeCycle, ContextAware, FilterAttachabl
   <code>ConsoleAppender</code></a>, as the name indicates, appends on
   the console, or more precisely on <em>System.out</em> or
   <em>System.err</em>, the former being the default
-  target. <code>ConsoleAppender</code> formats events with the hellp
-  of an encoder specified by the user. Encoders will be discussed in a
+  target. <code>ConsoleAppender</code> formats events with the help of
+  an encoder specified by the user. Encoders will be discussed in a
   subsequent chapter. Both <em>System.out</em> and <em>System.err</em>
   are of type <code>java.io.PrintStream</code>.  Consequently, they
   are wrapped inside an <code>OutputStreamWriter</code> which buffers
@@ -586,8 +586,7 @@ public interface Appender&lt;E> extends LifeCycle, ContextAware, FilterAttachabl
    below</a>) will determine if and exactly when rollover
    occurs. Thus, <code>RollingPolicy</code> is responsible for the
    <em>what</em> and <code>TriggeringPolicy</code> is responsible for
-   the <em>when</em>. <code>RollingPolicy</code> is described
-   </p>
+   the <em>when</em>. </p>
 	
    <p>To be of any use, a <code>RollingFileAppender</code> must have
    both a <code>RollingPolicy</code> and a
@@ -906,9 +905,10 @@ public interface RollingPolicy extends LifeCycle {
    interfaces.
    </p>
 
-   <p><code>TimeBasedRollingPolicy</code>'s admits two properties, the
-   mandatory <span class="option">fileNamePattern</span> property and
-   the optional <span class="option">maxHistory</span> property.
+   <p><code>TimeBasedRollingPolicy</code>'s configuration admits two
+   properties, the mandatory <span
+   class="option">fileNamePattern</span> property and the optional
+   <span class="option">maxHistory</span> property.
    </p>
 
    <table class="bodyTable">
@@ -2142,7 +2142,7 @@ Context ctx = new InitialContext(env);</pre>
    <p>The <a
    href="../xref/ch/qos/logback/classic/net/SMTPAppender.html"><code>SMTPAppender</code></a>
    accumulates logging events in one or more fixed-size buffers and
-   sends the contents of the appropriate bugger in an email after a
+   sends the contents of the appropriate bufferer in an email after a
    user-specified event occurs.  By default, the email transmission is
    triggered by a logging event of level ERROR or higher. Moreover, by
    default, a single buffer is used for all events.
diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html
index 3af7059..b4a5841 100644
--- a/logback-site/src/site/pages/manual/architecture.html
+++ b/logback-site/src/site/pages/manual/architecture.html
@@ -745,11 +745,11 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
   <h4>1. Get the filter chain decision</h4>
 
   <p>If it exists, the <code>TurboFilter</code> chain is
-  invoked. Turbo filters can set a context-wide threshold, or to
-  filter out certain events based on information such as
-  <code>Marker</code>, <code>Level</code>, <code>Logger</code>,
-  message, or the <code>Throwable</code> that are associated with each
-  logging request.  If the reply of the filter chain is
+  invoked. Turbo filters can set a context-wide threshold, or filter
+  out certain events based on information such as <code>Marker</code>,
+  <code>Level</code>, <code>Logger</code>, message, or the
+  <code>Throwable</code> that are associated with each logging
+  request.  If the reply of the filter chain is
   <code>FilterReply.DENY</code>, then the logging request is
   dropped. If it is <code>FilterReply.NEUTRAL</code>, then we continue
   with the next step, i.e. step 2. In case the reply is
@@ -880,12 +880,12 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
     and 4 microseconds to format a message with 1 and 3 parameters.
   </p>
 
-  <p> Please notice that, despite the performance points that we just
-  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
-  your application even if logging is turned off, and if logging is
-  turned on, they will generate massive (and hence useless) output.
+  <p> Please notice that, despite the performance points just
+  discussed, inserting logging statements in tight loops (very
+  frequently invoked code) is a lose-lose proposal and is likely to
+  result in degraded performance.  Logging in tight loops will slow
+  down your application even if logging is turned off, and if logging
+  is turned on, will generate massive (and hence useless) output.
   </p>
 
   <h4>2. The performance of deciding whether to log or not to log when
diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html
index 769d170..9782baf 100644
--- a/logback-site/src/site/pages/manual/configuration.html
+++ b/logback-site/src/site/pages/manual/configuration.html
@@ -218,7 +218,7 @@ public class Foo {
     </div>   
 
    <p>The <code>MyApp1</code> application links to logback via calls
-   <code>org.slf4j.LoggerFactory</code> and
+   to <code>org.slf4j.LoggerFactory</code> and
    <code>org.slf4j.Logger</code> classes, retrieve the loggers it
    wishes to use, and chugs on.  Note that the only dependencies of
    the <code>Foo</code> class on logback are through
@@ -527,7 +527,7 @@ public class MyApp3 {
    currently in effect, creates a new <code>JoranConfigurator</code>,
    sets the context on which it will operate, resets the logger
    context, and then finally asks the configurator to configure the
-   context using configuration file passed as parameter to the
+   context using the configuration file passed as a parameter to the
    application. Internal status data is printed in case of warnings or
    errors.
    </p>   
@@ -547,7 +547,7 @@ public class MyApp3 {
    data associated with a logback context. To keep memory usage at
    reasonable levels, the default <code>StatusManager</code>
    implementation stores the status messages in two separate parts:
-   the header part and the tail part. The header part stores the fist
+   the header part and the tail part. The header part stores the first
    <em>H</em> status messages whereas the tail part stores the last
    <em>T</em> messages. At present time <em>H</em>=<em>T</em>=150,
    although these values may change in future releases.</p>
@@ -709,12 +709,12 @@ public class MyApp3 {
     href="#loggerElement">Configuring loggers, or the
     <code>&lt;logger></code> element</a></h4>
 
-    <p>At this point should have at least some understanding of <a
+    <p>At this point you should have at least some understanding of <a
     href="architecture.html#effectiveLevel">level inheritance</a> and
     the <a href="architecture.html#basic_selection">basic selection
     rule</a>. Otherwise, and unless you are an egyptologist, logback
-    configuration will be no more meaningful to you than
-    are hieroglyphics.
+    configuration will be no more meaningful to you than are
+    hieroglyphics.
     </p>
 
     <p>A logger is configured using the <code>&lt;logger></code>
@@ -893,7 +893,7 @@ public class MyApp3 {
   <p>Let us note that the <a
   href="architecture.html#basic_selection">basic-selection rule</a>
   depends on the effective level of the logger being invoked, not the
-  level of the logger where appenders are attached. Loback will first
+  level of the logger where appenders are attached. Logback will first
   determine whether a logging statement is enabled or not, and if
   enabled, it will invoke the appenders found in the logger hierarchy,
   regardless of their level. The configuration file
@@ -976,7 +976,7 @@ public class MyApp3 {
   <h4><a name="configuringAppenders"
   href="#configuringAppenders">Configuring Appenders</a></h4>
 
-  <p>An appenders is configured with the <code>&lt;appender></code>
+  <p>An appender is configured with the <code>&lt;appender></code>
   element, which takes two mandatory attributes <span
   class="attr">name</span> and <span class="attr">class</span>.  The
   <span class="attr">name</span> attribute specifies the name of the
@@ -1051,7 +1051,7 @@ public class MyApp3 {
   &lt;/root>
 &lt;/configuration></pre>
 
-  <p>This configuration scripts defines two appenders called
+  <p>These configuration scripts define two appenders called
   <em>FILE</em> and <em>STDOUT</em>.  The <em>FILE</em> appender logs
   to a file called <em>myApp.log</em>. The encoder for this appender
   is a <code>PatternLayoutEncoder</code> that outputs the date, level,
@@ -1113,12 +1113,14 @@ public class MyApp3 {
 14:25:36.359 [main] INFO  chapters.configuration.MyApp3 - Exiting application.</p>
 
   <p>Notice the duplicated output. The appender named <em>STDOUT</em>
-  is attached to two loggers, to root and to <em>chapters.configuration</em>. Since
-  the root logger is the ancestor of all loggers and <em>chapters.configuration</em>
-  is the parent of <em>chapters.configuration.MyApp3</em> and <em>chapters.configuration.Foo</em>,
-  logging request made with these two loggers will be output twice,
-  once because <em>STDOUT</em> is attached to <em>chapters.configuration</em> and
-  once because it is attached to <em>root</em>.
+  is attached to two loggers, to root and to
+  <em>chapters.configuration</em>. Since the root logger is the
+  ancestor of all loggers and <em>chapters.configuration</em> is the
+  parent of both <em>chapters.configuration.MyApp3</em> and
+  <em>chapters.configuration.Foo</em>, each logging request made with
+  these two loggers will be output twice, once because <em>STDOUT</em>
+  is attached to <em>chapters.configuration</em> and once because it
+  is attached to <em>root</em>.
   </p>
 
   <p>Appender additivity is not intended as a trap for new users.  It
@@ -1219,10 +1221,10 @@ public class MyApp3 {
   <h3><a name="contextName" href="#contextName">Setting the context name</a></h3>
 
   <p>As mentioned <a href="architecture.html#LoggerContext">in an
-  earlier chapter</a>, every logger is attached to logger context. By
-  default, the logger context is called "default". However, you can
-  set a different name with the help of the
-  <code>&lt;contextName></code> configuration directive. Note that
+  earlier chapter</a>, every logger is attached to a logger
+  context. By default, the logger context is called
+  "default". However, you can set a different name with the help of
+  the <code>&lt;contextName></code> configuration directive. Note that
   once set, the logger context name <a
   href="../apidocs/ch/qos/logback/core/ContextBase.html#setName(java.lang.String)">cannot
   be changed</a>. Setting the context name is a simple and
@@ -1247,8 +1249,8 @@ public class MyApp3 {
   &lt;/root>
 &lt;/configuration></pre>
 
-  <p>This last examples illustrates naming of the logger
-  context. Adding the the <a
+  <p>This last example illustrates naming of the logger
+  context. Adding the <a
   href="layouts.html#conversionWord">contextName conversion word</a>
   in layout's pattern will output the said name.</p>
   
@@ -1363,9 +1365,9 @@ public class MyApp3 {
 
    <p>This configuration file contains a reference to a file named
    <em>variables1.properties</em>.  The variables contained in that
-   file will be read defined within the context of the logback
-   configuration file. Here is what the <em>variable.properties</em>
-   file might look like.
+   file will be read and then defined within the context of the
+   logback configuration file. Here is what the
+   <em>variable.properties</em> file might look like.
    </p>
 
    <em>Example: Variable file
@@ -1598,7 +1600,7 @@ fileName=myApp.log
    <p>Under certain circumstances, you may want to make use of
    env-entries stored in JNDI. The <code>&lt;insertFromJNDI></code>
    configuration directive extracts an env-entry stored in JNDI and
-   inserts it as variable as specified by the <span
+   inserts it as a variable whose key is as specified by the <span
    class="attr">as</span> attribute.
    </p>
 
diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html
index 1e10a0f..481d609 100644
--- a/logback-site/src/site/pages/manual/introduction.html
+++ b/logback-site/src/site/pages/manual/introduction.html
@@ -50,7 +50,7 @@
     existing logging systems, sometimes by a wide margin. Logback also
     offers unique and rather useful features such as Markers,
     parameterized logging statements, conditional stack tracing and
-    powerful event filtering. These are only few examples of useful
+    powerful event filtering. These are only a few examples of useful
     features logback has to offer. For its own error reporting,
     logback relies on <code>Status</code> objects, which greatly
     facilitate troubleshooting. You may wish to rely on Status objects
@@ -220,7 +220,7 @@ public class HelloWorld2 {
     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
+    namely the debug(), info(), warn() and error() methods. This will
     produce logging output on the configured appenders.</li>
   </ol>
  

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

Summary of changes:
 logback-site/src/site/pages/manual/appenders.html  |   18 +++---
 .../src/site/pages/manual/architecture.html        |   22 ++++----
 .../src/site/pages/manual/configuration.html       |   52 ++++++++++---------
 .../src/site/pages/manual/introduction.html        |    4 +-
 4 files changed, 49 insertions(+), 47 deletions(-)


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


More information about the logback-dev mailing list