[logback-dev] [GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.25-46-g4556c00
added by portage for gitosis-gentoo
git-noreply at pixie.qos.ch
Mon Dec 20 20:29:34 CET 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 4556c00a26f4aaee2d44d9d3fdff642297c32ffa (commit)
from cf96aaf8191b6312ed715c1f4729986205f8645f (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=4556c00a26f4aaee2d44d9d3fdff642297c32ffa
http://github.com/ceki/logback/commit/4556c00a26f4aaee2d44d9d3fdff642297c32ffa
commit 4556c00a26f4aaee2d44d9d3fdff642297c32ffa
Author: Ceki Gulcu <ceki at qos.ch>
Date: Mon Dec 20 20:27:13 2010 +0100
applied Inigo Surguy's proof reading patch
diff --git a/logback-site/src/site/pages/access.html b/logback-site/src/site/pages/access.html
index e639bf1..faf68c4 100644
--- a/logback-site/src/site/pages/access.html
+++ b/logback-site/src/site/pages/access.html
@@ -166,7 +166,7 @@
<p>The <a
href="xref/ch/qos/logback/access/jetty/RequestLogImpl.html">
<code>ch.qos.logback.access.jetty.RequestLogImpl</code></a> class
- implements jetty's <code><a
+ implements Jetty's <code><a
href="http://jetty.mortbay.org/apidocs/org/mortbay/jetty/RequestLog.html">RequestLog</a></code>
interface. Jetty delegates the management of access logging
functionality to implementations of this interface.
@@ -180,7 +180,7 @@
<p>In order to configure Jetty to use logback-access's
<code>RequestLogImpl</code>, please add the following lines to
- jetty's main configuration file, namely
+ Jetty's main configuration file, namely
<em>$JETTY_HOME/etc/jetty.xml</em>:
</p>
<pre class="prettyprint source"><Ref id="requestLog">
@@ -200,8 +200,8 @@
</p>
<p>As long the path is specified, you can place the logback
- configuration file in any location. Here is another example of
- jetty configuration file, including the path to the
+ configuration file in any location. Here is another example of a
+ Jetty configuration file, including the path to the
<em>logback-access.xml</em> configuration file.
</p>
@@ -473,7 +473,7 @@ CLASSPATH="$CLASSPATH":"$CATALINA_HOME"/bin/mx4j-impl.jar</pre></div>
<p>Here is the output generated when accessing the <a
href="demo.html">logback-demo</a> application configured as shown
- above, yields:</p>
+ above:</p>
<p class="source"><b>GET /logback-demo/index.jsp HTTP/1.1</b>
Host: localhost:8080
diff --git a/logback-site/src/site/pages/bugreport.html b/logback-site/src/site/pages/bugreport.html
index b22e383..07c30c6 100644
--- a/logback-site/src/site/pages/bugreport.html
+++ b/logback-site/src/site/pages/bugreport.html
@@ -25,7 +25,7 @@
<p>The logback community consists of those who use logback and its
modules, help answer questions on discussions lists, contribute
documentation and patches, and those who develop and maintain its
- code. Almost all those who assist on a day to day basis resolving
+ code. Those who assist on a day to day basis resolving
bug reports do this for a wide variety of reasons, and almost all
of them do this on their own time.</p>
diff --git a/logback-site/src/site/pages/codes.html b/logback-site/src/site/pages/codes.html
index 8a936c8..9fa6bd7 100644
--- a/logback-site/src/site/pages/codes.html
+++ b/logback-site/src/site/pages/codes.html
@@ -193,7 +193,7 @@
</p>
<p>A <code>Layout</code> is mandatory for
- <code>SMTPAppender</code>. It allows SMPTPAppender to format logging
+ <code>SMTPAppender</code>. It allows SMTPAppender to format logging
events before sending an email.
</p>
@@ -378,7 +378,7 @@
</p>
<p>Given that <code>FixedWindowRollingPolicy</code> performs
- multiple file rename operations suring roll over, and that these
+ multiple file rename operations during roll over, and that these
operations cannot be guaranteed to be safe in a multi-JVM context,
prudent mode is not allowed in conjuction with a
<code>FixedWindowRollingPolicy</code>.
@@ -399,7 +399,7 @@
contents of the message sent to the syslog daemon.
</p>
- <p>For more information on SyslogAppeder please refer to the <a
+ <p>For more information on SyslogAppender please refer to the <a
href="manual/appenders.html#SyslogAppender">its documentation.</a>
</p>
diff --git a/logback-site/src/site/pages/consolePlugin.html b/logback-site/src/site/pages/consolePlugin.html
index 8079cbb..aa66d1b 100644
--- a/logback-site/src/site/pages/consolePlugin.html
+++ b/logback-site/src/site/pages/consolePlugin.html
@@ -60,7 +60,7 @@
</p>
<p>
- Once the transfert is complete, unzip the file called
+ Once the transfer is complete, unzip the file called
<code>ch.qos.logback.eclipse_<em>VERSION</em>.zip</code>. Place the folder
found inside the archive in the following directory: <em>ECLIPSE_INSTALL/plugins/</em>
where <em>ECLIPSE_INSTALL</em> is the directory where you've installed Eclipse.
@@ -93,7 +93,7 @@
events to the localhost, on port <em>4321</em> by default. That's all it takes to run your
software and log to the logback plugin. By default, logging events are not filtered, but please
keep in mind that context-wide filtering in your logging configuration may affect the events
- that are recieved by the logback plugin.
+ that are received by the logback plugin.
</p>
<p>If you already have
@@ -127,8 +127,8 @@
<p>
The first button on the left clears the console. The second button toggles
- the auto-scroll functionnality. When enabled, you will always see the latest
- logs that have been recieved by the plugin. If you disable the auto scrolling,
+ the auto-scroll functionality. When enabled, you will always see the latest
+ logs that have been received by the plugin. If you disable the auto scrolling,
the view will display the current logs, and add the new ones at the bottom of
the list.
</p>
@@ -152,15 +152,15 @@
<p>
Double-clicking on a log entry will open a Java editor and show you the line
- where the entry was requested. It is an easy way to be access directly
- to the class and method that logged the selected entry.
+ where the entry was requested. It is an easy way to directly access
+ the class and method that logged the selected entry.
</p>
<p>
When an icon is shown on the left of the logging event, it means that the
logging event contains a stacktrace. Right-clicking on the line reveals
a sub-menu that lets you open Eclipse's StackTrace Console and display the
- stacktrace. You can click on the underlined parts of the stack trace to open
+ stacktrace. You can click on the underlined parts of the stacktrace to open
an editor revealing the selected class.
</p>
@@ -224,7 +224,7 @@
view before the list is trimmed. By default, the logback plugin will display
20'000 events. Once this number is reached, the plugin automatically drops
the 30% oldest logs. Please note that changing this value to a too much higher
- value might lead to memory issues, or even crashing Eclipse.
+ value might lead to memory issues, or even crash Eclipse.
</p>
@@ -232,12 +232,12 @@
<p>
The logback plugin lets you filter logging events when they are
- recieved. It uses the powerfull <code>EvaluatorFilter</code>objects
+ received. It uses the powerful <code>EvaluatorFilter</code> objects
that are available in logback. For detailled information about these filters, you might want
to check the <a href="manual/filters.html">corresponding documentation</a>
in the logback manual. In this document, we will only
cover some basic points, enough to get you started using the filtering
- functionnality of the logback plugin.
+ functionality of the logback plugin.
</p>
<p>
@@ -254,8 +254,8 @@
</p>
<p>
- A filter is composed of three informations. First, a Java expression,
- that will be evaluated for each logging event that is recieved by
+ A filter is composed of three pieces of information. First, a Java expression,
+ that will be evaluated for each logging event that is received by
the logback plugin. This expression can use a set of common variables
such as <code>level</code>, <code>logger</code>, <code>message</code>,
and several others. For a complete list of available variables, please
@@ -264,8 +264,9 @@
</p>
<p>
- The second and third informations that compose a filter are the
- action that will be taken depending on the result of the evaluation.
+ The second and third pieces of information that compose a filter are the
+ actions that will be taken depending on the result of the evaluation, for
+ a filter match and a filter mismatch.
Three actions are possible: <em>ACCEPT</em>, <em>DENY</em>
or <em>NEUTRAL</em>. Setting a filter's reply to <em>ACCEPT</em>
or <em>DENY</em> will prevent the plugin from evaluating any
@@ -302,7 +303,7 @@
We've just created a filter that will drop any requests whose
level is lower than <em>INFO</em>. Note the use of the <em>NEUTRAL</em>
value as the action to be taken when the filter is matched. Since
- we do not know what other filters might want to do, there is not reason
+ we do not know what other filters might want to do, there is no reason
to stop evaluating when the level is higher or equal to <em>INFO</em>.
</p>
@@ -317,7 +318,7 @@
</p>
<p>
- You should now be ready to experience the logback plugin and use its functionnalites.
+ You should now be ready to experience the logback plugin and use its functionality.
If you have any question about its use, feel free to use the logback
<a href="mailinglist.html">mailing lists</a>.
</p>
diff --git a/logback-site/src/site/pages/demo.html b/logback-site/src/site/pages/demo.html
index 60565e0..207ebc8 100644
--- a/logback-site/src/site/pages/demo.html
+++ b/logback-site/src/site/pages/demo.html
@@ -62,7 +62,7 @@
and a <code>RollingFileAppender</code>. The
<code>RollingFileAppender</code> sends logging events to a file
called <em>logFile.log</em> and will rollover the active file every
- minute. The old file will be renamed and compressed to <em>zip</em>
+ minute. The old file will be renamed and compressed to a <em>zip</em>
file. The <code>ConsoleAppender</code> will output the logging
requests to the console, and shorten the logger names to gain space
on the console window, without loss of legibility. For example,
@@ -71,8 +71,8 @@
</p>
<p>We highly encourage you to study the <em>logback.xml</em>
- configuratiun file located under the <em>src/main/resources/</em>
- folder. You might want to keep open this file in an editor window,
+ configuration file located under the <em>src/main/resources/</em>
+ folder. You might want to keep this file open in an editor window,
since we will modify its contents thoughout the demo.
</p>
@@ -82,7 +82,7 @@
created up until now. <code>Status</code> objects are a part of
logback's internal reporting framework. They allow you to see what
is going on inside logback, and check that a configuration file has
- been parsed correctly, or that a rollovers occur as expected.
+ been parsed correctly, or that rollovers occur as expected.
</p>
<p>You should be seeing log messages printed on the console and the
@@ -90,7 +90,7 @@
</p>
<p>If you visit the <em>View logs</em> page (by clicking on the link
- located in the menu on the left), you should see empty contemts. Let
+ located in the menu on the left), you should see it has no content. Let
us change that by uncommenting <strong>two</strong> parts in the
config file.</p>
@@ -107,23 +107,23 @@
<appender-ref ref="CYCLIC" />
--></p>
- <p>The <code><appender-ref></code> element element, found at the
+ <p>The <code><appender-ref></code> element found at the
end of the configuration file links an appender to a given logger,
in this particular case the root logger.
</p>
- <p>A <code>CyclicBuffer</code> keeps track of incoming logging event
+ <p>A <code>CyclicBuffer</code> keeps track of the incoming logging event
stream in a <a
href="http://en.wikipedia.org/wiki/Circular_buffer">circular
buffer</a> for later display. After having removed the comments
- around the two elemetns shown above, reload the logback-demo
+ around the two element/s shown above, reload the logback-demo
web-application by exiting the previous "mvn" command with
<em>CTRL-C</em> and issuing it again:
</p>
<p class="source">mvn package jetty:run</p>
- <p>This time <em>View logs</em> page should have contents.</p>
+ <p>This time the <em>View logs</em> page should have contents.</p>
<img src="images/cyclicView.png" alt="view logs"/>
@@ -140,7 +140,7 @@
<em>Howdydy-diddly-ho</em> messages is wasteful. We can get rid of
them with an appropriate filter. Uncomment the block entitled
<em>Cyclic buffer with Evaluator</em>. You should then comment the
- block entitled "Basic Cyclic buffer" that we uncommmented
+ block entitled "Basic Cyclic buffer" that we uncommented
earlier.</p>
<p>Let's take a look at the filter we've just added: </p>
@@ -157,12 +157,12 @@
</filter></p>
<p>The <code><expression></code> element uses the familiar
- Java-language syntax. It checks that the name of the logger contains
+ Java language syntax. It checks that the name of the logger contains
the String <em>LoggingTask</em>, but also that its message contains
the string <em>Howdydy-diddly-ho</em>. Moreover, in order to be
sure that the <em>Howdydy-diddly-ho</em> task actually works, we add
a last condition which checks that that at least 20 seconds have
- elapsed after application launch. The variables references in the
+ elapsed after application launch. The variable references in the
expression, namely (<code>logger</code>, <code>message</code> and
<code>event</code>) are implicitly made available by logback. The
<code><OnMatch></code> element lets the user specify the filter's
@@ -177,7 +177,7 @@
<h4>Turbo Filters</h4>
- <p>Logback support with a special category of filters called
+ <p>Logback supports a special category of filters called
TurboFilters. <code>TurboFilter</code> objects are ultra-fast,
context-wide filters. They can be very useful by setting
context-wide (i.e. global) conditions for enabling or disabling
@@ -212,17 +212,17 @@
...
</root></p>
- <p>Now restart the server as previously</p>
+ <p>Now restart the server as before.</p>
- <p>Once on the demo main webpage again, perform a number of actions
+ <p>Once on the main demo webpage again, perform a number of actions
(e.g. calculate a few prime numbers) and visit the <em>View
logs</em> page. The table should be empty.
</p>
- <p>Now log in into the logback-demo web-application with the
+ <p>Now login to the logback-demo web-application with the
username <em>sebastien</em> and perform a few prime
computations. The <em>View logs</em> page should show the logging
- events thgat were generated. Moreover, each logging event will have
+ events that were generated. Moreover, each logging event will have
an MDC field associated with the name of the logged in user, in this
case, sebastien. Please log off before continuing the demo, using
the <em>logout</em> button on the left.
@@ -230,10 +230,10 @@
<img src="images/turboFilterForMDC.png" alt="mdc filters"/>
- <h4>Parametrized logging</h4>
+ <h4>Parameterized logging</h4>
<p><a
- href="http://www.slf4j.org/faq.html#logging_performance">Parametrized
+ href="http://www.slf4j.org/faq.html#logging_performance">Parameterized
logging </a> is not a logback feature per se. It is part of
SLF4J. Usually, a logging request is issued as follows:
</p>
@@ -253,9 +253,9 @@
if the log statement is enabled.
</p>
- <p>At present, let us see what kind of gain can we expect from this
+ <p>At present, let us see what kind of gain we can expect from this
alternative approach. First, go to the <em>Prime number</em> page
- and compute factors for intergers of your choice. Check the time it
+ and compute factors for integers of your choice. Check the time it
takes to compute the results. To see a clearer difference between
the two formatting methods, you might want to try the two big
integers that are listed below the prime number textbox. Jot down
@@ -263,7 +263,7 @@
</p>
<p>Now let us edit the <code>NumberCruncherImpl</code> class in
- order to use parametrized logging. You will find this class in the
+ order to use parameterized logging. You will find this class in the
<em>src/main/java/ch/qos/logback/demo/prime/</em> directory. Comment
line 54 (doing unconditional message concatenation) and uncomment
line 55 (parameterized logging). Restart the server with <em>mvn
@@ -271,11 +271,11 @@
beforehand.
</p>
- <p>The time required to complete the computation should much lower
+ <p>The time required to complete the computation should be much lower
this time. Remember that we have turned off all logging in the
previous step of this demo. In the initial version, we were
constructing the message (<em>"Trying "+i+" as a factor."</em>) each
- time a factor was tested. With the paramatrized logging, the
+ time a factor was tested. With the parameterized logging, the
construction of the message was postponed and, since logging was
turned off, never done. Thus, parameterized logging can
significantly reduce the cost of disabled log statements.
@@ -287,16 +287,16 @@
part of the SLF4J API. If you look at the LoggingTask class (part of
logback-demo) which includes the <em>Howdydy-diddly-ho</em> log
statement, you should see that it is bound to a marker named
- <code>HOWDY</code> marker. Assume we wish to drop log statements
- bearing the <code>HOWDY</code> marker. Here is the
- <code>TurboFilter</code> to do just that.
+ <code>HOWDY</code> marker. If you wish to drop log statements
+ bearing the <code>HOWDY</code> marker, you can use this
+ <code>TurboFilter</code> to do so:
</p>
<p class="source"><turboFilter class="ch.qos.logback.classic.turbo.MarkerFilter">
<Name>HOWDY_FILTER</Name>
- <Marker>HOWDY</Marker>
- <OnMatch>DENY</OnMatch>
- </turboFilter> </p>
+ <Marker>HOWDY</Marker>
+ <OnMatch>DENY</OnMatch>
+</turboFilter> </p>
<p>After you have set the root logger's level back to <em>DEBUG</em>
and uncommented the MarkerFilter block in <em>logback.xml</em>,
@@ -305,7 +305,7 @@
<p>The logs bearing the <em>Howdydy-diddly-ho</em> message should no
- longer appear as they associated with a HOWDY marker. You can check
+ longer appear as they are associated with a HOWDY marker. You can check
that by visiting the <em>View Logs</em> page.
</p>
@@ -335,20 +335,20 @@
</configuration></pre></div>
<p>Note that logback-classic and logback-access are configured via
- different files, <em>logback.xml</em> and respectively
- <em>logback-acces.xml</em>. At present time, you might want to turn
+ different files: <em>logback.xml</em> and
+ <em>logback-access.xml</em> respectively. If you wanted to turn
off logging for logback-classic by setting the level of the root
- logger to OFF. Logback-access will be unaffected by this change.
+ logger to OFF, logback-access would be unaffected by this change.
</p>
- <p>To see the logs produced by logback access, just visit a few
+ <p>To see the logs produced by logback-access, just visit a few
pages and look at your console. The information contained in each
line has been specified in the configuration file. The
<code>ConsoleAppender</code> named <em>STDOUT</em> contains a
- <code>PatternLayout</code> component. This very component that one
- uses in logback classic to display either the message, logger name
- or level of the request is used in logback access to display the
- request method, requested page, status code and many others.
+ <code>PatternLayout</code> component. This layout component is
+ used in logback-classic to display either the message, logger name
+ or level of the request, but in logback-access it is used to display the
+ request method, requested page, status code and many other fields.
</p>
<p>Here is a sample output for this appender.</p>
@@ -377,7 +377,7 @@
page is accessed.
</p>
- <p>The configuration lines that are necessary are listed below.
+ <p>The necessary configuration lines are listed below.
</p>
<p class="source"><appender name="STDOUT_LOTTERY"
@@ -421,31 +421,31 @@
now. At every try, logback will produce a log as shown below:
</p>
- <p class="source">LOTTERY: 192.168.1.6 [POST /logback-demo/Lottery.do HTTP/1.1] Guess=321</p>>
+ <p class="source">LOTTERY: 192.168.1.6 [POST /logback-demo/Lottery.do HTTP/1.1] Guess=321</p>
<h4>Sending emails</h4>
- <p>Logback access provides several components that are usually used
+ <p>Logback-access provides several components that are usually used
by the classic module. For example, a <code>SMTPAppender</code> can
be used to send an email when a specific event occurs. Here, we will
contact the lottery administrator each time a winner is detected. To
achieve this, we will add a <code>SMTPAppender</code> to the
existing configuration. Please uncomment the part of
<em>logback-access.xml</em> named <em>Lottery to Email</em>. Do not
- forget to uncomment the <em>appender-ref</em> element, at the end of
- the configuration file, referencing the appender called
- <em>SMTP</em>. In the appender element, notice the use of a
- <code>URLEvaluator</code>. This evaluator allows us to only specify
- one or more URLs that have to be watched. When one of them are
+ forget to uncomment the <em>appender-ref</em> element at the end of
+ the configuration file that references the <em>SMTP</em> appender.
+ In the appender element, notice the use of a
+ <code>URLEvaluator</code>. This evaluator allows us to specify
+ one or more URLs that are to be watched. When one of them is
accessed, an email is sent.
</p>
<p>A reload of the configuration has to be done before we can test
this new component. Once done, try to play the lottery with the
- number <em>99</em>. You should see a congratulation message but,
+ number <em>99</em>. You should see a "congratulation" message but,
most importantly, the specified recipients should have a new mail in
their mailbox. The content of the email is a nicely formatted HTML
- table with informations about the access that have occured before
+ table with information about the accesses that occurred before
the triggering event.
</p>
@@ -454,12 +454,12 @@
<p>Logback publishes several components via JMX. This allows you to
see the status of certain objects, and change several configuration
parameters. Publishing logback's components via JMX is possible
- with Jetty and Tomcat. For more information about JMXConfigurator
+ with Jetty and Tomcat. For more information about the JMXConfigurator
please refer to the <a href="manual/jmxConfig.html">relevant
chapter</a> in the manual.
</p>
- <p>Let us test the level setting possibility of the configurator.
+ <p>Let us test setting levels using the configurator.
The <em>Prime Number</em> page requests two types of logs. When the
calculation checks if a number is a factor, a <em>DEBUG</em> log is
displayed. When the calculation has found a factor, a <em>INFO</em>
diff --git a/logback-site/src/site/pages/documentation.html b/logback-site/src/site/pages/documentation.html
index 841ac67..bdfcf72 100644
--- a/logback-site/src/site/pages/documentation.html
+++ b/logback-site/src/site/pages/documentation.html
@@ -51,7 +51,7 @@
</li>
<li>
- <a href="demo.html">Walk-through logback-demo webApp</a>
+ <a href="demo.html">Walk-through logback-demo web app</a>
</li>
<li>
<a href="consolePlugin.html">User guide of the logback plugin for Eclipse</a>
diff --git a/logback-site/src/site/pages/download.html b/logback-site/src/site/pages/download.html
index 5ec28b3..634a00d 100644
--- a/logback-site/src/site/pages/download.html
+++ b/logback-site/src/site/pages/download.html
@@ -63,9 +63,9 @@
<p>A console plugin for Eclipse is also available. It allows you
- to recieve logging events in a convenient Eclipse view, and
- offers, among other features, integrates with logbacks filtering
- framework. A more precise description can be found in the plugin's
+ to receive logging events in a convenient Eclipse view, and
+ offers integration with logback's filtering
+ framework, among other features. A more precise description can be found in the plugin's
<a href="consolePlugin.html">user guide</a>. <b>Unfortunately, the
console plugin is somewhat outdated. It expects logback version
0.9.9. It will be upgraded in the coming weeks.</b></p>
@@ -112,9 +112,9 @@
<h2>Forks</h2>
- <p>At present time there are 13 forks of logback on github. If you
- are the author of one of those forks and would like feedback from
- potential users, plase drop us a line at logback-dev mailing list
+ <p>At present time there are 18 forks of logback on github. If you
+ are the author of one of these forks and would like feedback from
+ potential users, please drop us a line at the logback-dev mailing list
with a brief description of your fork. We will gladly add a link to
your fork to the list below (currently empty).</p>
diff --git a/logback-site/src/site/pages/faq.html b/logback-site/src/site/pages/faq.html
index 78477d4..195f83e 100644
--- a/logback-site/src/site/pages/faq.html
+++ b/logback-site/src/site/pages/faq.html
@@ -92,7 +92,7 @@
<dd>
<p>The logback project is dual licensed under the LGPL and
- the EPL for two mains reasons. For one, the different
+ the EPL for two main reasons. For one, the different
license emphasizes that the fact that logback is a related
but <em>different</em> project than log4j.
</p>
@@ -213,7 +213,7 @@
href="manual/configuration.html#variableSubstitution">variable
substitution</a>, it is possible to have a single
configuration file to output logs to different destinations
- depending on each JEE application. Here is a sample
+ for each JEE application. Here is a sample
configuration file designed for this purpose.</p>
<p class="source"><configuration>
@@ -242,7 +242,7 @@
</p>
<p class="source"> LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
- // inject the name of the current application as "applicaiton-name"
+ // inject the name of the current application as "application-name"
// property of the LoggerContext
<b>context.putProperty("application-name", NAME_OF_CURRENT_APPLICATION);</b>
JoranConfigurator jc = new JoranConfigurator();
@@ -262,9 +262,9 @@
</a>
</dt>
<dd>
- <p>Logback does not allow disabling logging from the command
+ <p>Logback does not allow logging to be disabled from the command
line. However, if the configuration file allows it, you can
- set the level of logers on the command line via a java
+ set the level of logers on the command line via a Java
system property. Here is such a configuration file.</p>
<p class="source"><configuration>
@@ -320,7 +320,7 @@
</p>
- <p>Since Jetty's uses an older version of SLF4J internally,
+ <p>Since Jetty uses an older version of SLF4J internally,
we recommend that the old version be replaced by
<em>slf4j-api-${slf4j.version}.jar</em>. This file can be
downloaded from the <a
@@ -328,7 +328,7 @@
</p>
- <p>For automaticly configuring logback-classic, you can
+ <p>For automatically configuring logback-classic, you can
place the file <em>logback.xml</em> under the
<em>$JETTY_HOME/resources</em> directory. You can find
sample configuration files in the
diff --git a/logback-site/src/site/pages/index.html b/logback-site/src/site/pages/index.html
index eef4e2b..1ec22f0 100644
--- a/logback-site/src/site/pages/index.html
+++ b/logback-site/src/site/pages/index.html
@@ -79,9 +79,9 @@
<ul>
<li><a href="http://jwebunit.sourceforge.net/quickstart.html">JWebUnit</a></li>
+ <li><a href="http://liftweb.net/">Lift</a></li>
<li><a href="http://www.opengda.org/">OpenGDA</a></li>
<li><a href="http://code.google.com/p/openmeetings/">OpenMeetings</a></li>
- <li><a href="http://liftweb.net/">Lift</a></li>
<li><a href="http://opentsdb.net/overview.html">OpenTSDB</a></li>
<li><a href="http://www.red5.org">Red5</a></li>
<li><a href="http://scalate.fusesource.org/">Scalate</a></li>
diff --git a/logback-site/src/site/pages/license.html b/logback-site/src/site/pages/license.html
index 2dbcc92..22e8995 100644
--- a/logback-site/src/site/pages/license.html
+++ b/logback-site/src/site/pages/license.html
@@ -24,8 +24,8 @@
</div>
- <p>As of relase 0.9.18, logback source code and binaries are
- dual-licensed under EPL v1.0 and the LGPL 2.1, or more
+ <p>As of release 0.9.18, logback source code and binaries are
+ dual-licensed under the EPL v1.0 and the LGPL 2.1, or more
formally:</p>
<p class="source">Logback: the reliable, generic, fast and flexible logging framework.
@@ -45,7 +45,7 @@ as published by the Free Software Foundation.</p>
<p>The EPL/LGPL dual-license serves several purposes. The LGPL
license ensures <em>continuity</em> in terms of licensing of the
logback project. Prior to version 0.9.18, logback was licensed
- (exlusively) under the LGPL v2.1. Moreover, since the EPL is
+ (exclusively) under the LGPL v2.1. Moreover, since the EPL is
deemed <a
href="http://www.fsf.org/licensing/licenses/index_htm">incompatible</a>
by the Free Software Foundation, the LGPL will allow various
@@ -64,14 +64,14 @@ as published by the Free Software Foundation.</p>
</p>
<p>If you wish to make a significant contribution to the logback
- project, you are invited to file <a href="cla.txt">Contributor
+ project, you are invited to file a <a href="cla.txt">Contributor
License Agreement</a>. The purpose of this agreement is to
formalize the terms of your contribution and to protect the
project in case of litigation.
</p>
<p>Upon request, we may exempt open-source projects from LGPL and
- EPL's reciprocity clauses so that the said pojects can develop
+ EPL's reciprocity clauses so that the said projects can develop
logback extensions under the license of their choice. Exemptions
are granted on a case by case basis.</p>
diff --git a/logback-site/src/site/pages/mailinglist.html b/logback-site/src/site/pages/mailinglist.html
index e6ee0fc..d114616 100644
--- a/logback-site/src/site/pages/mailinglist.html
+++ b/logback-site/src/site/pages/mailinglist.html
@@ -33,9 +33,9 @@
<h3>Respect the mailing list type</h3>
- <p>The "User" lists where you can send questions and comments
+ <p>The "User" lists are where you can send questions and comments
about configuration, setup, usage and other "user" types of
- questions. The "Developer" lists where you can send questions and
+ questions. The "Developer" lists are where you can send questions and
comments about the actual software source code and other issues
related to development.
</p>
@@ -46,7 +46,7 @@
</p>
<p>Please do your best to ensure that you are not sending HTML or
- "Stylelized" email to the list. If you are using Outlook or
+ "Styled" email to the list. If you are using Outlook or
Outlook Express or Eudora, chances are that you are sending HTML
email by default. There is usually a setting that will allow you
to send "Plain Text" email.
@@ -151,7 +151,7 @@
<h2>On IRC</h2>
- <p>We can also be reached by IRC at <span
+ <p>We can also be reached on IRC at <span
class="big"><code>irc.freenode.net#qos.ch</code></span>. </p>
<p> </p>
diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html
index 0f326e8..6e87946 100644
--- a/logback-site/src/site/pages/manual/appenders.html
+++ b/logback-site/src/site/pages/manual/appenders.html
@@ -68,7 +68,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
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
+ will vary depending on the logback module. Within the
logback-classic module <em>E</em> would be of type <a
href="../apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html">ILoggingEvent</a>
and within the logback-access module it would be of type <a
@@ -134,7 +134,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
return;
}
- // ok, we now invoke derived class' implementation of append
+ // ok, we now invoke the derived class's implementation of append
this.append(eventObject);
} finally {
@@ -156,7 +156,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
href="../xref/ch/qos/logback/core/UnsynchronizedAppenderBase.html"><code>ch.qos.logback.core.UnsynchronizedAppenderBase</code></a>
which is very similar to the <a
href="../xref/ch/qos/logback/core/AppenderBase.html"><code>AppenderBase</code></a>
- class. For the sake of conciseness, we want to be discussing
+ class. For the sake of conciseness, we will be discussing
<code>UnsynchronizedAppenderBase</code> in the remainder of this document.
</p>
@@ -183,7 +183,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
an appender, Joran, logback's configuration framework, calls the
<code>start()</code> method to signal the appender to activate its
properties. Depending on its kind, an appender may fail to start if
- certain properties are missing or because of interferences between
+ certain properties are missing or because of interference between
various properties. For example, given that file creation depends on
truncation mode, <code>FileAppender</code> cannot act on the value
of its <code>File</code> option until the value of the Append option
@@ -202,7 +202,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
<p>The next <code>if</code> statement checks the result of the
attached filters. Depending on the decision resulting from the
- filter chain, events can be denied or alternatively accepted. In
+ filter chain, events can be denied or explicitly accepted. In
the absence of a decision by the filter chain, events are accepted
by default.
</p>
@@ -242,7 +242,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
appends events to a <code>java.io.OutputStream</code>. This class
provides basic services that other appenders build upon. Users do
not usually instantiate <code>OutputStreamAppender</code> objects
- directly. Since in general the <code>java.io.OutputStream</code>
+ directly, since in general the <code>java.io.OutputStream</code>
type cannot be conveniently mapped to a string, as there is no way
to specify the target <code>OutputStream</code> object in a
configuration script. Simply put, you cannot configure a
@@ -431,7 +431,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
href="#prudent">prudent</a></span></b></td>
<td><code>boolean</code></td>
- <td>In prudent mode, <code>FileAppeder</code> will safely
+ <td>In prudent mode, <code>FileAppender</code> will safely
write to the specified file, even in the presence of other
<code>FileAppender</code> instances running in different
JVMs, potentially running on different hosts. The default
@@ -553,7 +553,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
available to subsequent configuration elements <a
href="configuration.html#variableSubstitution">as a
variable</a>. The <span class="attr">datePattern</span> attribute
- denoted the date pattern used to convert the current time (at which
+ denotes the date pattern used to convert the current time (at which
the configuration file is parsed) into a string. The date pattern
should follow the conventions defined in <a
href="http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html">SimpleDateFormat</a>.
@@ -569,7 +569,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
<p><a
href="../xref/ch/qos/logback/core/rolling/RollingFileAppender.html"><code>RollingFileAppender</code></a>
- extends <code>FileAppender</code> with the capability to roll log
+ extends <code>FileAppender</code> with the capability to rollover log
files. For example, <code>RollingFileAppender</code> can log to a
file named <em>log.txt</em> file and, once a certain condition is
met, change its logging target to another file.
@@ -593,7 +593,7 @@ public interface Appender<E> extends LifeCycle, ContextAware, FilterAttachabl
<code>TriggeringPolicy</code> set up. However, if its
<code>RollingPolicy</code> also implements the
<code>TriggeringPolicy</code> interface, then only the former needs
- to be set up.
+ to be specified explicitly.
</p>
<p>Here are the available properties for <code>RollingFileAppender</code>:</p>
@@ -701,7 +701,7 @@ public interface RollingPolicy extends LifeCycle {
<p>The <code>rollover</code> method accomplishes the work involved
in archiving the current log file. The
- <code>getActiveFileName()</code> method is called to compute a the
+ <code>getActiveFileName()</code> method is called to compute the
file name of the current log file (where live logs are written
to). As indicated by <code>getCompressionMode</code> method a
RollingPolicy is also responsible for determining the compression
@@ -760,11 +760,11 @@ public interface RollingPolicy extends LifeCycle {
<td>
<p>This option represents the pattern that will be followed
by the <code>FixedWindowRollingPolicy</code> when renaming
- the log files. If must contain the string <em>%i</em>, which
+ the log files. It must contain the string <em>%i</em>, which
will indicate the position where the value of the current
window index will be inserted.
</p>
- <p>For example, using <em>MyLogFile%i.log</em>, associated
+ <p>For example, using <em>MyLogFile%i.log</em> associated
with minimum and maximum values of <em>1</em> and <em>3</em>
will produce archive files named <em>MyLogFile1.log</em>,
<em>MyLogFile2.log</em> and <em>MyLogFile3.log</em>.
@@ -772,7 +772,7 @@ public interface RollingPolicy extends LifeCycle {
<p>Note that file compression is also specified via this
property. For example, <span
class="option">fileNamePattern</span> set to
- <em>MyLogFile%i.log.zip</em> means that archived file must be
+ <em>MyLogFile%i.log.zip</em> means that archived files must be
compressed using the <em>zip</em> format; <em>gz</em> format
is also supported.
</p>
@@ -905,7 +905,7 @@ public interface RollingPolicy extends LifeCycle {
interfaces.
</p>
- <p><code>TimeBasedRollingPolicy</code>'s configuration admits two
+ <p><code>TimeBasedRollingPolicy</code>'s configuration has two
properties, the mandatory <span
class="option">fileNamePattern</span> property and the optional
<span class="option">maxHistory</span> property.
@@ -922,7 +922,7 @@ public interface RollingPolicy extends LifeCycle {
<td><code>String</code></td>
<td>
The mandatory <span class="option">fileNamePattern</span>
- property defines the name of the rolled (archived) log
+ property defines the name of the rolled-over (archived) log
files. Its value should consist of the name of the file, plus
a suitably placed <em>%d</em> conversion specifier. The
<em>%d</em> conversion specifier may contain a date-and-time
@@ -1317,9 +1317,9 @@ public interface TriggeringPolicy<E> extends LifeCycle {
}</pre>
<p>The <code>isTriggeringEvent()</code> method takes as parameters
- the active file, and the logging event currently being
+ the active file and the logging event currently being
processed. The concrete implementation determines whether the
- rollover should occur or not, based on the said parameters.
+ rollover should occur or not, based on these parameters.
</p>
<p>The most widely-used triggering policy, namely
@@ -1333,7 +1333,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p><a
href="../xref/ch/qos/logback/core/rolling/SizeBasedTriggeringPolicy.html">
- <code>SizeBasedTriggeringPolicy</code></a> looks at size of the
+ <code>SizeBasedTriggeringPolicy</code></a> looks at the size of the
currently active file. If it grows larger than the specified size,
it will signal the owning <code>RollingFileAppender</code> to
trigger the rollover of the existing active file.
@@ -1354,7 +1354,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p>Here is a sample configuration with a
<code>RollingFileAppender</code> in conjunction with
- <code>SizeBasedTriggeringPolicy</code> triggering roll over when
+ <code>SizeBasedTriggeringPolicy</code> triggering rollover when
the log file reaches 5MB in size.
</p>
@@ -1404,7 +1404,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<a name="SocketAppender" href="#SocketAppender">SocketAppender</a>
</h3>
- <p>The appenders covered this far were only able to log on local
+ <p>The appenders covered thus far are only able to log to local
resources. In contrast, the <a
href="../xref/ch/qos/logback/classic/net/SocketAppender.html">
<code>SocketAppender</code></a> is designed to log to a remote
@@ -1419,7 +1419,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
locally. Multiple <code>SocketAppender</code> instances running on
different machines can direct their logging output to a central
log server whose format is fixed. <code>SocketAppender</code>
- does not admit an associated layout because it sends serialized
+ does not take an associated layout because it sends serialized
events to a remote server. <code>SocketAppender</code> operates
above the <em>Transmission Control Protocol (TCP)</em> layer which
provides a reliable, sequenced, flow-controlled end-to-end octet
@@ -1751,7 +1751,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
</p>
<p>By specifying a discriminator other than the default
- one, it would be possible to receive email messages
+ one, it is possible to receive email messages
containing a events pertaining to a particular user, user
session or client IP address.
</p>
@@ -1766,7 +1766,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p>This option is declared by creating a new
<code><EventEvaluator/></code> element. The name of the
class that the user wishes to use as the
- <code>SMTPAppender</code>'s <code>Evaluator</code> can needs
+ <code>SMTPAppender</code>'s <code>Evaluator</code> needs
to be specified via the <span class="attr">class</span>
attribute.
</p>
@@ -1879,7 +1879,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
download the <a
href="http://java.sun.com/products/javamail/">JavaMail API</a> and
the <a
- href="http://java.sun.com/beans/glasgow/jaf.html">Java-Beans
+ href="http://java.sun.com/beans/glasgow/jaf.html">JavaBeans
Activation Framework</a> from their respective websites. Make
sure to place these two jar files in the classpath before trying
the following examples.
@@ -1887,7 +1887,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p>A sample application, <a
href="../xref/chapters/appenders/mail/EMail.html"><code>chapters.appenders.mail.EMail</code></a>
- generates a number of log messages messages followed by a single
+ generates a number of log messages followed by a single
error message. It takes two parameters. The first parameter is an
integer corresponding to the number of logging events to
generate. The second parameter is the logback configuration
@@ -1939,7 +1939,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p>In the next example configuration file <em>mail2.xml</em>, the
values for the <span class="option">smtpHost</span>, <span
- class="option">To</span> and <span class="option">From</span>
+ class="option">to</span> and <span class="option">from</span>
properties are determined by variable substitution. Here is the
relevant part of <em>mail2.xml</em>.
</p>
@@ -1984,8 +1984,8 @@ public interface TriggeringPolicy<E> extends LifeCycle {
However, they sometimes automatically downgrade HTML to
plaintext. For example, to view HTML email in Thunderbird, the
"View→Message Body As→Original HTML" option
- must be set. Yahoo!Mail's support for HTML email, in particular
- its CSS support is very good. GMail on the other hand, while it
+ must be set. Yahoo! Mail's support for HTML email, in particular
+ its CSS support is very good. Gmail on the other hand, while it
honors the basic HTML table structure, ignores the internal CSS
formatting. Gmail supports inline CSS formatting but since inline
CSS would make the resulting output too voluminous,
@@ -2024,7 +2024,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<p>If the Evaluator property is not set, the
<code>SMTPAppender</code> defaults to an <a
- href="../xref/ch/qos/logback/classic/boolex/OnErrorEvaluator.html">OnErrorEveluator</a>
+ href="../xref/ch/qos/logback/classic/boolex/OnErrorEvaluator.html">OnErrorEvaluator</a>
instance which triggers email transmission when it encounters an
event of level ERROR. While triggering an outgoing email in
response to an error is relatively reasonable, it is possible to
@@ -2040,7 +2040,7 @@ public interface TriggeringPolicy<E> extends LifeCycle {
<code>SMTPAppender</code> contains one and only one evaluator
object. This object may manage its own internal state. For
illustrative purposes, the <code>CounterBasedEvaluator</code>
- class listed next, implements an event evaluator whereby every
+ class listed next implements an event evaluator whereby every
1024th event triggers an email message.
</p>
@@ -2120,7 +2120,7 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval
based triggering</a>
</h3>
- <p>Although reasonable the default triggering policy whereby every
+ <p>Although reasonable, the default triggering policy whereby every
event of level ERROR triggers an outgoing email may result in too
many emails, cluttering the targeted user's mailbox. Logback ships
with another triggering policy, called <a
@@ -2232,7 +2232,7 @@ logger.error(<b>notifyAdmin</b>,
<p>Note that since the event may lack a marker, the value of
e.marker can be null. Hence the use of Groovy's <a
href="http://groovy.codehaus.org/Null+Object+Pattern">safe
- derefencing opeator</a>, that is the .? operator.
+ dereferencing operator</a>, that is the .? operator.
</p>
@@ -2325,7 +2325,7 @@ logger.error(<b>notifyAdmin</b>,
session or client IP address, depending on the specified discriminator.
</p>
- <p>The next example illustrates the use of<a
+ <p>The next example illustrates the use of <a
href="../xref/ch/qos/logback/classic/sift/MDCBasedDiscriminator.html">MDCBasedDiscriminator</a>
in conjunction with the MDC key named "req.remoteHost", assumed to
contain the IP address of the remote host accessing a fictitious
@@ -2362,7 +2362,7 @@ logger.error(<b>notifyAdmin</b>,
</root>
</configuration></pre>
- <p>Thus, each outgoing emails generated by
+ <p>Thus, each outgoing email generated by
<code>SMTPAppender</code> will belong to a <em>unique</em> remote
host, greatly facilitating problem diagnosis.
</p>
@@ -2397,7 +2397,7 @@ logger.error(<b>notifyAdmin</b>,
<p>If your JDBC driver supports the <code>getGeneratedKeys</code>
method introduced in JDBC 3.0 specification, assuming you have
created the appropriate database tables as mentioned above, then
- no more steps are required, excluding the usual logback
+ no more steps are required, except for the usual logback
configuration.
</p>
@@ -2772,7 +2772,7 @@ logger.error(<b>notifyAdmin</b>,
</configuration></pre>
<p>
- Not that in this configuration sample, we make heavy use of substitution variables.
+ Note that in this configuration sample, we make heavy use of substitution variables.
They are sometimes handy when connection details have to be centralized in a
single configuration file and shared by logback and other frameworks.
</p>
@@ -2800,7 +2800,7 @@ logger.error(<b>notifyAdmin</b>,
source will be bound to a JNDI context.
</p>
- <p>This is a very powerful possibility of Joran. If you'd like to
+ <p>This is a very powerful capability of Joran. If you'd like to
read more about Joran, please see the <a
href="onJoran.html">chapter to Joran</a>.
</p>
@@ -2969,7 +2969,7 @@ logger.error(<b>notifyAdmin</b>,
</td>
<td>
The port number on the syslog server to connect to. Normally, one would not want
- to change the default value, that is <em>514</em>.
+ to change the default value of <em>514</em>.
</td>
</tr>
<tr class="b">
@@ -2987,7 +2987,7 @@ logger.error(<b>notifyAdmin</b>,
the source of a message.
</p>
<p>
- The <span class="option">facility</span> option must be set one
+ The <span class="option">facility</span> option must be set to one
of the strings <em>KERN, USER, MAIL, DAEMON, AUTH, SYSLOG, LPR, NEWS, UUCP,
CRON, AUTHPRIV, FTP, NTP, AUDIT, ALERT, CLOCK, LOCAL0, LOCAL1, LOCAL2,
LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7</em>. Case is not important.
@@ -3024,7 +3024,7 @@ logger.error(<b>notifyAdmin</b>,
<p>
Since the format of a syslog request follows rather strict rules, there is no layout
- to be used with <code>SyslogAppender</code>. However, the using the
+ to be used with <code>SyslogAppender</code>. However, using the
<span class="option">suffixPattern</span> option lets the user display whatever
information she wishes.
</p>
@@ -3336,7 +3336,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> {
</p>
<p>Two tables are used by <code>DBAppender</code>:
- <em>access_event</em> and <em>access_event_header</em>. They all
+ <em>access_event</em> and <em>access_event_header</em>. They both
must exist before <code>DBAppender</code> can be used. Logback
ships with SQL scripts that will create the tables. They can be
found in the
@@ -3414,7 +3414,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> {
<p>
The <em>access_event_header</em> table contains the header of each
- requests. The information is organised as shown below:
+ request. The information is organised as shown below:
</p>
<table class="bodyTable">
@@ -3441,7 +3441,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> {
</table>
<p>All properties of classic's <code>DBAppender</code> are available
- in access' <code>DBAppender</code>. The latter offers one more option,
+ in access's <code>DBAppender</code>. The latter offers one more option,
described below.
</p>
@@ -3495,7 +3495,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> {
logback-access the default discriminator, namely <a
href="../xref/ch/qos/logback/access/sift/AccessEventDiscriminator.html">AccessEventDiscriminator</a>,
is not MDC based. As its name suggests, AccessEventDiscriminator,
- uses a designated field in AccessEvent as basis for selecting a
+ uses a designated field in AccessEvent as the basis for selecting a
nested appender. If the value of the designated field is null,
then the value specified in the <span
class="option">defaultValue</span> property is used.
diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html
index b4a5841..939636b 100644
--- a/logback-site/src/site/pages/manual/architecture.html
+++ b/logback-site/src/site/pages/manual/architecture.html
@@ -56,9 +56,9 @@
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>.
+ Servlet containers to provide HTTP-access log functionality. A
+ separate document covers
+ <a href="../access.html">access module documentation</a>.
</p>
<p>In the reminder of this document, we will write "logback" to
@@ -152,8 +152,8 @@ public interface Logger {
href="#effectiveLevel">Effective Level aka Level Inheritance</a>
</h3>
- <p>Loggers may be assigned levels. The set of possible levels,
- that is TRACE, DEBUG, INFO, WARN and ERROR are defined in the
+ <p>Loggers may be assigned levels. The set of possible levels
+ (TRACE, DEBUG, INFO, WARN and ERROR) are defined in the
<code>ch.qos.logback.classic.Level</code> class. Note that in
logback, the <code>Level</code> class is final and cannot be
sub-classed, as a much more flexible approach exists in the form
@@ -477,7 +477,7 @@ Logger y = LoggerFactory.getLogger("wombat");</pre>
<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
+ parenthood, where parents always precede 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.
@@ -573,7 +573,7 @@ Logger y = LoggerFactory.getLogger("wombat");</pre>
<td>A1</td>
<td>Since the root logger stands at the top of the logger
- hiearchy, the additivity flag does not apply to it.
+ hierarchy, the additivity flag does not apply to it.
</td>
</tr>
<tr class="alt">
@@ -665,7 +665,7 @@ Logger y = LoggerFactory.getLogger("wombat");</pre>
<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,
+ to a String, and concatenating intermediate strings. This is
regardless of whether the message will be logged or not.
</p>
@@ -698,11 +698,11 @@ Logger y = LoggerFactory.getLogger("wombat");</pre>
<pre class="prettyprint source">Object entry = new SomeObject();
logger.debug("The entry is {}.", entry);</pre>
- <p>After evaluting whether to log or not, and only if the decision
+ <p>Only after evaluating 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.
+ construction when the log statement is disabled.
</p>
@@ -716,7 +716,7 @@ logger.debug("The entry is {}.", entry);</pre>
logger.debug("The new entry is {}.", entry);</pre>
- <p>A two argument variant is also availalble. For example, you can
+ <p>A two argument variant is also available. For example, you can
write:
</p>
@@ -807,7 +807,7 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
String. Note that some appenders, such as the
<code>SocketAppender</code>, do not transform the logging event into
a string but serialize it instead. Consequently, they do not
- require nor have a layout.
+ have nor require a layout.
</p>
<h4>6. Sending out the <code>LoggingEvent</code></h4>
@@ -876,8 +876,8 @@ logger.debug("Value {} was inserted between {} and {}.", paramArray);</pre>
margin. The message will be formatted only if the request is
processed to the appenders. If it is processed, the component
that formats the message offers high performance and does not
- impact negatively the overall process. It respectively takes 2
- and 4 microseconds to format a message with 1 and 3 parameters.
+ negatively impact the overall process. It takes 2
+ and 4 microseconds respectively to format a message with 1 and 3 parameters.
</p>
<p> Please notice that, despite the performance points just
diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html
index ce31db1..372b410 100644
--- a/logback-site/src/site/pages/manual/configuration.html
+++ b/logback-site/src/site/pages/manual/configuration.html
@@ -44,7 +44,7 @@
<p>Joran stands for a cold north-west wind which, every now and
then, blows forcefully on Lake Geneva. Located right in the middle
- of Europe, the Geneva lake happens to be the continent's largest
+ of Europe, Lake Geneva happens to be the continent's largest
sweet water reserve.
</p>
@@ -105,10 +105,10 @@
classpath</a>..</p>
</li>
- <li><p>In case neither file is found, logback configures itself
+ <li><p>If neither file is found, logback configures itself
automatically using the <a
href="../xref/ch/qos/logback/classic/BasicConfigurator.html"><code>BasicConfigurator</code></a>
- which will cause logging output to be directed on the console.
+ which will cause logging output to be directed to the console.
</p>
</li>
@@ -120,8 +120,8 @@
</p>
- <p>If you are using Maven and assuming the
- <em>logback-test.xml</em> file is placed under
+ <p>If you are using Maven and if you place the
+ <em>logback-test.xml</em> under the
<em>src/test/resources</em> folder, Maven will ensure that it
won't be included in the artifact produced. Thus, you can use a
different configuration file, namely <em>logback-test.xml</em>
@@ -225,8 +225,8 @@ public class Foo {
<code>org.slf4j.LoggerFactory</code> and
<code>org.slf4j.Logger</code> imports. Except code that configures
logback (if such code exists) client code does not need to depend
- on logback. Given that SLF4J permits the use of any logging
- framework under its abstraction layer, it is rather easy to migrate
+ on logback. Since SLF4J permits the use of any logging
+ framework under its abstraction layer, it is easy to migrate
large bodies of code from one logging framework to another.
</p>
@@ -282,7 +282,7 @@ public class Foo {
wish to inspect logback's internal status, then you can instruct
logback to print status data by invoking the <code>print()</code>
of the <code>StatusPrinter</code> class. The <em>MyApp2</em>
- application shown below is identical to <em>MyApp1</em> except the
+ application shown below is identical to <em>MyApp1</em> except for the
addition of two lines of code for printing internal status
data.</p>
@@ -357,8 +357,8 @@ public class Foo {
</configuration></pre>
<p>Setting the <code>debug</code> attribute within the
- <configuration> element will output status information, under
- the assumption that
+ <configuration> element will output status information,
+ assuming that:
</p>
<ol>
<li>the configuration file is found</li>
@@ -366,21 +366,20 @@ public class Foo {
</ol>
<p>If any of these two conditions is not fulfilled, Joran cannot
- interpret <code>debug</code> attribute since the configuration file
+ interpret the <code>debug</code> attribute since the configuration file
cannot be read. If the configuration file is found but is
- ill-formed, then logback will detect the error condition and
+ malformed, then logback will detect the error condition and
automatically print its internal status on the console. However, if
- the configuration file cannot be found, since this is not
- necessarily an error condition, logback will not automatically
- print its status data. Programmatically invoking
- <code>StatusPrinter.print()</code>, as as in <em>MyApp2</em>
- application above, ensures that status information is always
+ the configuration file cannot be found, logback will not automatically
+ print its status data, since this is not necessarily an error condition. Programmatically invoking
+ <code>StatusPrinter.print()</code> as in the <em>MyApp2</em>
+ application above ensures that status information is always
printed.
</p>
- <p>It is highly recommended to register a status listener,
+ <p>It is strongly recommended to register a status listener,
e.g. <code>OnConsoleStatusListener</code>, so that problems
- occuring during the lifetime of your applicaiton, well after
+ occuring during the lifetime of your application, well after
logback is initialized, can be reported. See the section on <a
href="#statusListener">status listeners</a> further below.</p>
@@ -390,7 +389,7 @@ public class Foo {
<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
+ <code>logback.configurationFile</code>. The value of this
property can be a URL, a resource on the class path or a path to a
file external to the application.
</p>
@@ -403,14 +402,14 @@ public class Foo {
<div class="highlight">
<p>Logback-classic can scan for changes in its configuration file
- and automatically reconfigure itself when the said configuration
+ and automatically reconfigure itself when the configuration
file changes.
</p>
</div>
<p>If instructed to do so, logback-classic will scan for changes in
its configuration file and automatically reconfigure itself when
- the said configuration file changes. In order to instruct
+ the configuration file changes. In order to instruct
logback-classic to scan for changes in its configuration file and
to automatically re-configure itself set the <span
class="attr">scan</span> attribute of the
@@ -455,7 +454,7 @@ public class Foo {
href="../xref/ch/qos/logback/classic/turbo/ReconfigureOnChangeFilter.html">ReconfigureOnChangeFilter</a>
will be installed. TurboFilters are described in a <a
href="filters.html#TurboFilter">later chapter</a>. As a
- consequence, scanning is done "in-thread", that is anytime a
+ consequence, scanning is done "in-thread", that is any time a
printing method of logger is invoked. For example, for a logger
named <code>myLogger</code>, when you write
"myLogger.debug("hello");", and if the scan attribute is set to
@@ -482,8 +481,8 @@ public class Foo {
<p>Logback relies on a configuration library called Joran which is
part of logback-core. Logback's default configuration mechanism
invokes <code>JoranConfigurator</code> on the default configuration
- file it finds on the class path. For whatever reason if you wish to
- override logback's default configuration mechanism, you can do so
+ file it finds on the class path. If you wish to
+ override logback's default configuration mechanism for whatever reason, you can do so
by invoking <code>JoranConfigurator</code> directly. The next
application, <em>MyApp3</em>, invokes JoranConfigurator on a
configuration file passed as a parameter.</p>
@@ -549,7 +548,7 @@ public class MyApp3 {
object, accessible via the <code>LoggerContext</code>.
</p>
- <p>Given a <code>StatusManager</code> you an access all the status
+ <p>Given a <code>StatusManager</code> you can access all the status
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:
@@ -581,7 +580,7 @@ public class MyApp3 {
<url-pattern>/lbClassicStatus</url-pattern>
</servlet-mapping></pre>
- <p>The <code>ViewStatusMessages</code> servlet will viewable under
+ <p>The <code>ViewStatusMessages</code> servlet will be viewable at
the URL <code>http://host/yourWebapp/lbClassicStatus</code>
</p>
@@ -618,7 +617,7 @@ public class MyApp3 {
OnConsoleStatusListener onConsoleListener = new OnConsoleStatusListener();
statusManager.add(onConsoleListener);</pre>
- <p>Note that the registered status listener will receive status
+ <p>Note that the registered status listener will only receive status
events subsequent to its registration. It will not receive prior
messages. Thus, it is usually a good idea to place status listener
registration directives at top of the configuration file before
@@ -646,7 +645,7 @@ public class MyApp3 {
<h2>
- <a name="syntax" href="#syntax">Configuration file Syntax</a>
+ <a name="syntax" href="#syntax">Configuration file syntax</a>
</h2>
<p>As you have seen thus far in the manual with plenty of examples
@@ -664,7 +663,7 @@ public class MyApp3 {
configuration files.
</p>
- <p>As shall be demonstrated over and over, the syntax of logback
+ <p>As will be demonstrated over and over, the syntax of logback
configuration files is extremely flexible. As such, it is not
possible to specify the allowed syntax with a DTD file or an XML
schema. Nevertheless, the very basic structure of the configuration
@@ -692,7 +691,7 @@ public class MyApp3 {
sensitivity of tag names</a></h4>
- <p>As of logback version 0.9.17, tag names pertaining to explicit
+ <p>Since logback version 0.9.17, tag names pertaining to explicit
rules are case insensitive. For example, both
<code><logger></code>, <code><Logger></code> and
<code><LOGGER></code> are valid configuration elements and will
@@ -703,9 +702,9 @@ public class MyApp3 {
rules</a>, tag names are case sensitive except for the first
letter. Thus, <code><xyz></code> and <code><Xyz></code> are
equivalent but not <code><xYz></code>. Implicit rules usually
- follow the <a href="http://en.wikipedia.org/wiki/CamelCase">camel
- case</a> convention, common in the Java world. Since it is not
- easy tell when a tag is associated with an explicit action and
+ follow the <a href="http://en.wikipedia.org/wiki/CamelCase">camelCase</a>
+ convention, common in the Java world. Since it is not
+ easy to tell when a tag is associated with an explicit action and
when it is associated with an implicit action, it is not trivial
to say whether an XML tag is case-sensitive or insensitive with
respect to the first letter. If you are unsure which case to use
@@ -720,7 +719,7 @@ public class MyApp3 {
<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
+ rule</a>. Otherwise, and unless you are an Egyptologist, logback
configuration will be no more meaningful to you than are
hieroglyphics.
</p>
@@ -731,18 +730,18 @@ public class MyApp3 {
<span class="attr">level</span> attribute, and an optional <span
class="attr">additivity</span> attribute, admitting the values
<em>true</em> or <em>false</em>. The value of the <span
- class="attr">level</span> attribute admitting the one of the
+ class="attr">level</span> attribute admitting one of the
case-insensitive string values TRACE, DEBUG, INFO, WARN, ERROR,
ALL or OFF. The special case-insensitive value <em>INHERITED</em>,
or its synonym <em>NULL</em>, will force the level of the logger
to be inherited from higher up in the hierarchy. This comes in
- handy in case you set the level of a logger and later decide that
+ handy if you set the level of a logger and later decide that
it should inherit its level.
</p>
<p>The <code><logger></code> element may contain zero or more
<code><appender-ref></code> elements; each appender thus
- referenced is added to the named logger. Note that contrary to
+ referenced is added to the named logger. Note that unlike
log4j, logback-classic does <em>not</em> close or remove any
previously referenced appenders before adding the new appender
reference.
@@ -754,23 +753,22 @@ public class MyApp3 {
logger, or the <code><root></code> element</a></h4>
<p>The <code><root></code> element configures the root
- logger. It admits a single attribute, namely the <span
- class="attr">level</span> attribute. It does not admit any other
+ logger. It supports a single attribute, namely the <span
+ class="attr">level</span> attribute. It does not allow any other
attributes because the additivity flag does not apply to the root
logger. Moreover, since the root logger is already named as
- "ROOT", it does not admit a name attribute either. The value of the
+ "ROOT", it does not allow a name attribute either. The value of the
level attribute can be one of the case-insensitive strings TRACE,
DEBUG, INFO, WARN, ERROR, ALL or OFF. Note that the level of the
root logger cannot be set to INHERITED or NULL.
</p>
- <p>The <code><root></code> element admits zero or more
- <code><appender-ref></code> elements. Similar to the
+ <p> Similarly to the
<code><logger></code> element, the <code><root></code>
element may contain zero or more <code><appender-ref></code>
elements; each appender thus referenced is added to the root
- logger. Note that contrary to log4j, logback-classic does
+ logger. Note that unlike log4j, logback-classic does
<em>not</em> close or remove any previously referenced appenders
before adding the new appender reference to the root logger.
</p>
@@ -818,7 +816,7 @@ public class MyApp3 {
<p>Note that the message of level DEBUG generated by the <a
href="../xref/chapters/configuration/Foo.html">"chapters.configuration.Foo"</a>
- logger has been supressed. See also the Foo class.</p>
+ logger has been suppressed. See also the Foo class.</p>
<p>You can configure the levels of as many loggers as you wish. In
the next configuration file, we set the level of the
@@ -993,9 +991,9 @@ public class MyApp3 {
instantiate. The <code><appender></code> element may contain zero
or one <code><layout></code> elements, zero or more
<code><encoder></code> elements and zero or more
- <code><filter></code> elements. Appart from these three common
+ <code><filter></code> elements. Apart from these three common
elements, <code><appender></code> elements may contain any number
- of elements corresponding to javabean properties of the appender
+ of elements corresponding to JavaBean properties of the appender
class. Seamlessly supporting any property of a given logback
component is one of the major strengths of <a
href="onJoran.html">Joran</a> as discussed in a later chapter. The
@@ -1010,7 +1008,7 @@ public class MyApp3 {
<p>The <code><layout></code> element takes a mandatory class
attribute specifying the fully qualified name of the layout class to
- instantiate. As with the the <code><appender></code> element,
+ instantiate. As with the <code><appender></code> element,
<code><layout></code> may contain other elements corresponding to
properties of the layout instance. Since it's such a common case, if
the layout class is <code>PatternLayout</code>, then the class
@@ -1132,7 +1130,7 @@ public class MyApp3 {
</p>
<p>Appender additivity is not intended as a trap for new users. It
- is a quite convenient logback feature. For instance, you can
+ is quite a convenient logback feature. For instance, you can
configure logging such that log messages appear on the console (for
all loggers in the system) while messages only from some specific
set of loggers flow into a specific appender.
@@ -1180,7 +1178,7 @@ public class MyApp3 {
<p>In case the default cumulative behavior turns out to be
unsuitable for your needs, you can override it by setting the
additivity flag to false. Thus, a branch in your logger tree may
- direct output to a set of appenders different than those of the rest
+ direct output to a set of appenders different from those of the rest
of the tree.
</p>
@@ -1275,7 +1273,7 @@ public class MyApp3 {
value of the substituted variable can be defined in the
configuration file itself, in an external properties file or as a
system property. The corresponding value replaces <em>${aKey}</em>
- sequence. For example, if <em>java.home.dir</em> system property is
+ sequence. For example, if the <em>java.home.dir</em> system property is
set to <em>/home/xyz</em>, then every occurrence of the sequence
<em>${java.home.dir}</em> will be interpreted as <em>/home/xyz</em>.
As they often come in handy, the ${HOSTNAME} and ${CONTEXT_NAME}
@@ -1291,7 +1289,7 @@ public class MyApp3 {
to remote hosts via serialization.</p>
<p>The next example shows a variable, a.k.a. a substitution
- property, declared the beginning of the configuration file. It is
+ property, declared at the beginning of the configuration file. It is
then used further down the file to specify the location of the
output file.
</p>
@@ -1405,7 +1403,7 @@ public class MyApp3 {
<h4>Nested variable substitution</h4>
- <p>Nested variabled subsitution is also supported. By nested, we
+ <p>Nested variable subsitution is also supported. By nested, we
mean that the value definition of a variable contains references to
other variables. Suppose you wish to use variables to specify not
only the destination directory but also the file name, and combine
@@ -1421,7 +1419,7 @@ fileName=myApp.log
<b>destination=${USER_HOME}/${fileName}</b></pre>
<p>Note that in the properties file above, "destination" is
- composed out of two other variables, namely "USER_HOME" and
+ composed from two other variables, namely "USER_HOME" and
"fileName".
</p>
@@ -1450,7 +1448,7 @@ fileName=myApp.log
variables</a></h3>
<p>Under certain circumstances, it may be desirable for a variable
- to have a default value in case it is not declared or its value is
+ to have a default value if it is not declared or its value is
null. As in the <a
href="http://tldp.org/LDP/abs/html/parameter-substitution.html">Bash
shell</a>, default values can be specified using the <b>":-"</b>
@@ -1509,7 +1507,7 @@ fileName=myApp.log
<root level="${rootLevel}"/>
</configuration></pre>
- <p>At present time, logback does not ship with any classes
+ <p>At the present time, logback does not ship with any classes
implementing <code>PropertyDefiner</code>. We merely provide an
extension point so that you may define properties dynamically.
</p>
@@ -1550,7 +1548,7 @@ fileName=myApp.log
</else>
</if></pre>
- <p>The condition is a java expression where only context properties
+ <p>The condition is a Java expression in which only context properties
or system properties are accessible. For a key passed as argument,
the <code>property</code>() or its shorter equivalent
<code>p</code>() methods return the String value of the property.
@@ -1558,7 +1556,7 @@ fileName=myApp.log
write <code>property("k")</code> or equivalently
<code>p("k")</code>. If the property with key "k" is undefined, the
property method will return the empty string and not null. This
- avoids the need to to check for null values. If you need to check
+ avoids the need to check for null values. If you need to check
whether a property is null, the <code>isNull()</code> method is
provided. For example, you can write <code>isNull("k")</code>.</p>
@@ -1602,7 +1600,7 @@ fileName=myApp.log
statements are also supported. However, XML syntax is awfully
cumbersome and is ill suited as the foundation of a general purpose
programming language. Consequently, too many conditionals will
- quickly render your configuration files ungrokable to subsequent
+ quickly render your configuration files incomprehensible to subsequent
readers, including yourself.
</p>
@@ -1684,7 +1682,7 @@ fileName=myApp.log
<p>Again, please note the mandatory
- <code class="big green"><included></code> element if you have not already done so.</p>
+ <code class="big green"><included></code> element.</p>
<p>The contents to include can be referenced as a file, as a
resource, or as a URL.</p>
@@ -1725,7 +1723,7 @@ fileName=myApp.log
<p><code>JMXConfigurator</code> is one implementation of the
- <code>LoggerContextListener</code> interface. It is desribed in a <a
+ <code>LoggerContextListener</code> interface. It is described in a <a
href="jmxConfig.html">subsequent chapter</a>.
</p>
@@ -1756,7 +1754,7 @@ fileName=myApp.log
<p>Setting the <span class="option">resetJUL</span> propery of
LevelChangePropagator will reset all previous level configurations
- of all j.u.l. loggers. Previously installed handlers however will be
+ of all j.u.l. loggers. However, previously installed handlers will be
left untouched.</p>
<pre class="prettyprint source"><configuration debug="false">
diff --git a/logback-site/src/site/pages/manual/encoders.html b/logback-site/src/site/pages/manual/encoders.html
index 70dc3de..ecd1000 100644
--- a/logback-site/src/site/pages/manual/encoders.html
+++ b/logback-site/src/site/pages/manual/encoders.html
@@ -47,10 +47,10 @@
layout to transform an event into a string and write it out using
a <code>java.io.Writer</code>. In previous versions of logback,
users would nest a <code>PatternLayout</code> within
- <code>FileAppender</code>. As for logback 0.9.19,
+ <code>FileAppender</code>. Since logback 0.9.19,
<code>FileAppender</code> and sub-classes <a
href="../codes.html#layoutInsteadOfEncoder">expect an encoder and no
- longer admit a layout</a>.
+ longer take a layout</a>.
</p>
<p>Why the breaking change?
@@ -61,14 +61,14 @@
layout has no control over when events get written out, layouts
cannot aggregate events into batches. Contrast this with encoders
which not only have total control over the format of the bytes
- written out, also control when (and if) those bytes get written
+ written out, but also control when (and if) those bytes get written
out.
</p>
<p>At the present time (2010-03-08),
<code>PatternLayoutEncoder</code> is the only really useful
encoder. It merely wraps a <code>PatternLayout</code> which does
- most of the work. Thus, may seem that encoders do not bring much
+ most of the work. Thus, it may seem that encoders do not bring much
to the table except needless complexity. However, we hope that
with the advent of new and powerful encoders this impression will
change.</p>
@@ -99,7 +99,7 @@ public interface Encoder<E> extends ContextAware, LifeCycle {
/**
* Encode and write an event to the appropriate {@link OutputStream}.
- * Implementations are free to differ writing out of the encoded event and
+ * Implementations are free to defer writing out of the encoded event and
* instead write in batches.
*/
void doEncode(E event) throws IOException;
@@ -113,8 +113,8 @@ public interface Encoder<E> extends ContextAware, LifeCycle {
void close() throws IOException;
}</pre>
- <p>As you can see, the Encoder interface consists of few method
- but surprisingly enough many useful things can be accomplished with
+ <p>As you can see, the Encoder interface consists of few methods,
+ but surprisingly many useful things can be accomplished with
those methods.
</p>
diff --git a/logback-site/src/site/pages/manual/filters.html b/logback-site/src/site/pages/manual/filters.html
index 5ae6f91..46d555c 100644
--- a/logback-site/src/site/pages/manual/filters.html
+++ b/logback-site/src/site/pages/manual/filters.html
@@ -63,9 +63,9 @@
<p>Regular logback-classic filters extend the <a
href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a>
- abstract class which essentially consists of a single method,
+ abstract class which essentially consists of a single
<code>decide()</code> method taking an <code>ILoggingEvent</code>
- instance as parameter.
+ instance as its parameter.
</p>
@@ -151,16 +151,16 @@ public class SampleFilter extends Filter>ILoggingEvent> {
</configuration></pre>
<p>With the help of Joran, logback's configuration framework,
- specifiying properties or sub-componenets to filters is also
+ specifying properties or sub-componenets to filters is also
easy. After adding the corresponding setter method in the filter
class, specify the value of the property in an xml element named
- after the property, nesting it within <code><filter></code>
+ after the property, nesting it within a <code><filter></code>
element.
</p>
- <p>Often times, the desired filter logic consists of two
+ <p>Often, the desired filter logic consists of two
orthogonal parts, a match/mismatch test and a response depending
- on the match/mismatch. For example, for a given test, say message
+ on the match/mismatch. For example, for a given test, e.g. message
equals "foobar", one filter might respond ACCEPT on match and
NEUTRAL on mismatch, and another filter might respond NEUTRAL on
match and DENY on mismatch.
@@ -169,8 +169,8 @@ public class SampleFilter extends Filter>ILoggingEvent> {
<p>Taking notice of this orthogonality, logback ships with the <a
href="../xref/ch/qos/logback/core/filter/AbstractMatcherFilter.html">
<code>AbstractMatcherFilter</code></a> class which provides a
- useful skeleton for specifiying the appropriate response on match
- and on mistmatch, with the help of two properties, named
+ useful skeleton for specifying the appropriate response on match
+ and on mismatch, with the help of two properties, named
<em>OnMatch</em> and <em>OnMismatch</em>. Most of the regular
filters included in logback are derived from
<code>AbstractMatcherFilter</code>.
@@ -248,14 +248,14 @@ public class SampleFilter extends Filter>ILoggingEvent> {
<p><a
href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a>
is a generic filter encapsulating an
- <code>EventEvaluator</code>. As the name intimates, an
+ <code>EventEvaluator</code>. As the name suggests, an
<a
href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html">
<code>EventEvaluator</code></a> evaluates whether a given criteria
- is met for a given event. On match and respectively on mismatch,
+ is met for a given event. On match and on mismatch,
the hosting <code>EvaluatorFilter</code> will return the value
- specified by <span class="option">onMatch</span> and respectively
- to <span class="option">onMismatch</span> properties.
+ specified by the <span class="option">onMatch</span>
+ or <span class="option">onMismatch</span> properties respectively.
</p>
@@ -274,10 +274,10 @@ public class SampleFilter extends Filter>ILoggingEvent> {
href="../xref/ch/qos/logback/classic/boolex/GEventEvaluator.html">GEventEvaluator</a>
is a concrete <a
href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html"><code>EventEvaluator</code></a>
- implementation taking artibtrary Groovy language boolean
- expressions as the evaluation criteria. We refer such groovy
- language boolean expressions as "groovy evalation
- expressions". Groovy evaluation expressions enable hereto
+ implementation taking arbitrary Groovy language boolean
+ expressions as the evaluation criteria. We refer such Groovy
+ language boolean expressions as "groovy evaluation
+ expressions". Groovy evaluation expressions enable hitherto
unprecedented flexibility in event
filtering. <code>GEventEvaluator</code> requires the Groovy
runtime. Please see the <a
@@ -289,18 +289,18 @@ public class SampleFilter extends Filter>ILoggingEvent> {
<p>Evaluation expressions are compiled on-the-fly during the
interpretation of the configuration file. As a user, you do not
need to worry about the actual plumbing. However, it is your
- reponsibility to ensure that the groovy-language expression is
+ responsibility to ensure that the groovy-language expression is
valid.
</p>
- <p>The evaluation expression acts on the current logging event,
- logback automatically inserts the current logging event of type <a
+ <p>The evaluation expression acts on the current logging event.
+ Logback automatically inserts the current logging event of type <a
href="../apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html">ILoggingEvent</a>
as a variable referred to as '<em>event</em>' as well as its
shorthand referred to as '<em>e</em>'. The variables TRACE, DEBUG,
INFO, WARN and ERROR are also exported into the scope of the
expression. Thus, "event.level == DEBUG" and "e.level == DEBUG"
- are equvalent and valid groovy expressions which will return
+ are equivalent and valid groovy expressions which will return
<code>true</code> only if the current logging event's level is
identical to DEBUG. For other comparison operators on levels, the
level field should be converted to integer with the
@@ -343,10 +343,10 @@ public class SampleFilter extends Filter>ILoggingEvent> {
checking whether the MDC associated with the event contains a
value for "req.userAgent" matching the
<code>/Googlebot|msnbot|Yahoo/</code> regular expression. Note
- that since the mdc map can be null, we are also using Groovy's <a
+ that since the MDC map can be null, we are also using Groovy's <a
href="http://groovy.codehaus.org/Null+Object+Pattern">safe
- derefencing opeator</a>, that is the .? operator. The equivalent
- logic would have be much longer to express in Java.
+ dereferencing operator</a>, that is the .? operator. The equivalent
+ logic would have been much longer if expressed in Java.
</p>
<p>If you are wondering how the identifier for the user agent was
@@ -366,8 +366,8 @@ public class SampleFilter extends Filter>ILoggingEvent> {
<p>Logback-classic ships with another concrete
<code>EventEvaluator</code> implementation called <a
href="../xref/ch/qos/logback/classic/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a>
- taking arbitrary java language boolean expressions as the
- evaluation criteria. We refer to such java language boolean
+ taking arbitrary Java language boolean expressions as the
+ evaluation criteria. We refer to such Java language boolean
expressions as "<em>evaluation expressions</em>". Evaluation
expressions enable great flexibility in event
filtering. <code>JaninoEventEvaluator</code> requires the <a
@@ -384,7 +384,7 @@ public class SampleFilter extends Filter>ILoggingEvent> {
<p>Evaluation expressions are compiled on-the-fly during the
interpretation of the configuration file. As a user, you do not
need to worry about the actual plumbing. However, it is your
- reponsibility to ensure that the java-language expression returns
+ reponsibility to ensure that the Java language expression returns
a boolean, i.e. that it evaluates to true or false. </p>
@@ -483,7 +483,7 @@ public class SampleFilter extends Filter>ILoggingEvent> {
'mdc' variable can be null and this possibility should be
checked for in evaluator expressions.
- <p>The <code>java.util.Map</code> type is non-parametirezied
+ <p>The <code>java.util.Map</code> type is non-parameterized
because Janino does not support generics. It follows that the
type returned by <code>mdc.get()</code> is <code>Object</code>
and not <code>String</code>. To invoke <code>String</code>
@@ -556,8 +556,8 @@ public class SampleFilter extends Filter>ILoggingEvent> {
evaluator of type <code>JaninoEventEvaluator</code> is then
injected into the <code>EvaluatorFilter</code>. In the absence of
<span class="attr">class</span> attribute in the
- <code><evaluator></code> element specified by the user, joran
- will infer a default type, i.e. <code>JaninoEventEvaluator</code>,
+ <code><evaluator></code> element specified by the user, Joran
+ will infer a default type of <code>JaninoEventEvaluator</code>
for the evaluator. This is one of the <a
href="onJoran.html#defaultClassMapping">few occurrences</a> where
Joran implicitly infers the type of a component.
@@ -675,7 +675,7 @@ java chapters.filters.FilterEvents src/main/java/chapters/filters/basicConfigura
266 [main] ERROR chapters.filters.FilterEvents - billing statement 6
266 [main] INFO chapters.filters.FilterEvents - logging statement 8</p>
- <p>In case you need to define additional matchers, you can do so by
+ <p>If you need to define additional matchers, you can do so by
adding further <code><matcher></code> elements.</p>
@@ -711,7 +711,7 @@ java chapters.filters.FilterEvents src/main/java/chapters/filters/basicConfigura
<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
- events, even before they are created.
+ events, even before the events are created.
</p>
@@ -776,11 +776,11 @@ public class SampleTurboFilter extends TurboFilter {
<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.
+ passes the responsibility 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
+ 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.
@@ -945,9 +945,9 @@ logger.debug("Hello {}.", name1);</pre>
<p>The number of allowed repetitions can be specified by the <span
class="option">AllowedRepetitions</span> property. For example, if
- the said property is set to 1, then the 2nd and subsequent
+ the property is set to 1, then the 2nd and subsequent
occurrences of the same message will be dropped. Similarly, if the
- said property is set to 2, then the 3rd and subsequent occurrences
+ property is set to 2, then the 3rd and subsequent occurrences
of the same message will be dropped. By default, the <span
class="option">AllowedRepetitions</span> property is set to 5.
</p>
@@ -1067,14 +1067,14 @@ logger.debug("Hello {}.", name1);</pre>
<p><a
href="../xref/ch/qos/logback/core/filter/EvaluatorFilter.html"><code>EvaluatorFilter</code></a>
is a generic filter encapsulating an
- <code>EventEvaluator</code>. As the name intimates, an
+ <code>EventEvaluator</code>. As the name suggests, an
<a
href="../xref/ch/qos/logback/core/boolex/EventEvaluator.html">
<code>EventEvaluator</code></a> evaluates whether a given criteria
- is met for a given event. On match and respectively on mismatch,
+ is met for a given event. On match and on mismatch,
the hosting <code>EvaluatorFilter</code> will return the value
- specified by <span class="option">onMatch</span> and respectively
- to <span class="option">onMismatch</span> properties. Note that
+ specified by the <span class="option">onMatch</span> or
+ <span class="option">onMismatch</span> properties respectively. Note that
<code>EvaluatorFilter</code> has been previously discussed in the
context of logback-classic (<a href="#evalutatorFilter">see
above</a>). The present text is mostly a repetition of the
@@ -1086,8 +1086,8 @@ logger.debug("Hello {}.", name1);</pre>
<code>EventEvaluator</code>. Logback-access ships with a concrete
implementation named <a
href="../xref/ch/qos/logback/access/boolex/JaninoEventEvaluator.html">JaninoEventEvaluator</a>.
- It takes arbitrary java language boolean expressions as the
- evaluation criteria. We refer to such java language boolean
+ It takes arbitrary Java language boolean expressions as the
+ evaluation criteria. We refer to such Java language boolean
expressions as "<em>evaluation expressions</em>". Evaluation
expressions enable great flexibility in event
filtering. <code>JaninoEventEvaluator</code> requires the <a
@@ -1100,7 +1100,7 @@ logger.debug("Hello {}.", name1);</pre>
<p>Evaluation expressions are compiled on-the-fly during the
interpretation of the configuration file. As a user, you do not
need to worry about the actual plumbing. However, it is your
- reponsibility to ensure that the java-language expression returns
+ reponsibility to ensure that the Java language expression returns
a boolean, i.e. that it evaluates to true or false. </p>
@@ -1109,7 +1109,7 @@ logger.debug("Hello {}.", name1);</pre>
<code>AccessEvent</code> instance under the variable name
<b><code>event</code></b>. You can read the various data
associated with the HTTP request as well as the HTTP response via
- the <code>event</code> variable. Please refer to the the <a
+ the <code>event</code> variable. Please refer to the <a
href="../xref/ch/qos/logback/access/spi/AccessEvent.html"><code>AccessEvent</code>
class source code</a> for the exact list.
</p>
@@ -1137,7 +1137,7 @@ logger.debug("Hello {}.", name1);</pre>
<appender-ref ref="STDOUT" />
</configuration></pre>
- <p>In the next example, we still log request resulting 404 errors,
+ <p>In the next example, we still log requests resulting in 404 errors,
except those requests asking for CSS files.
</p>
diff --git a/logback-site/src/site/pages/manual/groovy.html b/logback-site/src/site/pages/manual/groovy.html
index 064dcb9..8e06a19 100644
--- a/logback-site/src/site/pages/manual/groovy.html
+++ b/logback-site/src/site/pages/manual/groovy.html
@@ -41,51 +41,51 @@
<script src="../templates/creative.js" type="text/javascript"></script>
- <p>Domains-specific languages or DSLs are rather pervasive. The
+ <p>Domain-specific languages or DSLs are rather pervasive. The
XML-based logback configuration can be viewed as a DSL
instance. By the very nature of XML, XML-based configuration files
are quite verbose and rather bulky. Moreover, a relatively large
- body of code in logback, namely Joran, is dedicated to processes
+ body of code in logback, namely Joran, is dedicated to processing
these XML-based configuration files. Joran supports nifty features
such as variable substitution, conditional processing and
- on-the-fly extensibility. However, not only Joran is a complex
+ on-the-fly extensibility. However, not only is Joran a complex
beast, the user-experience it provides can be described as
unsatisfactory or at the very least unintuitive.
</p>
<p>The Groovy-based DSL described in this chapter aims to be
- consistent, intuitive, and powerful. Everything you can do XML in
+ consistent, intuitive, and powerful. Everything you can do using XML in
configuration files, you can do in Groovy with a much shorter
syntax. To help you migrate to Groovy style configuration, we have
- developped a <a
+ developed a <a
href="http://logback.qos.ch/translator/asGroovy.html">tool to
- automatically migrate your existing<em>logback.xml</em> files to
+ automatically migrate your existing <em>logback.xml</em> files to
<em>logback.groovy</em></a>.
</p>
<h2>General philosophy</h2>
- <p>As a general rule, <em>logback.groovy</em> files are groovy
- programs. And since groovy is a super-set of Java, whatever
+ <p>As a general rule, <em>logback.groovy</em> files are Groovy
+ programs. And since Groovy is a super-set of Java, whatever
configuration actions you can perform in Java, you can do the same
within a <em>logback.groovy</em> file. However, since configuring
logback progammatically using Java syntax can be cumbersome, we
added a few logback-specific extensions to make your life
easier. We try hard to limit the number of logback-specific
syntactic extensions to an absolute minimum. If you are already
- familiar with groovy, you should be able to read, understand and
+ familiar with Groovy, you should be able to read, understand and
even write your own <em>logback.groovy</em> files with great
ease. Those unfamiliar with Groovy should still find
<em>logback.groovy</em> syntax much more comfortable to use than
<em>logback.xml</em>.
</p>
- <p>Given that <em>logback.groovy</em> files are groovy programs
- with minimal logback-specific extensins, <em>all</em> the usual
+ <p>Given that <em>logback.groovy</em> files are Groovy programs
+ with minimal logback-specific extensions, <em>all</em> the usual
groovy constructs such as class imports, variable definitions,
evaluation of ${..} expressions contained in strings
- (GStrings), if-else statements are all avaiable in
+ (GStrings), and if-else statements are available in
<em>logback.groovy</em> files.</p>
<h2>Extensions specific to <em>logback.groovy</em></h2>
@@ -105,7 +105,7 @@
the root logger. As an optional second argument of type
<code>List<String></code>, can be used to attach previously
defined appenders by name. If you do not specify the list of
- appender names, then an empty list is assumed. In groovy, an empty
+ appender names, then an empty list is assumed. In Groovy, an empty
list is denoted by <code>[]</code>.</p>
<p>To set the level of the root logger to WARN, you would write:</p>
@@ -138,14 +138,14 @@ root(INFO, ["CONSOLE", "FILE"])</pre>
href="architecture.html#effectiveLevel">inherit its level</a> from
its nearest ancestor with an assigned level. The third argument of
type <code>List<String></code> is optional and defaults to an
- emtpy list if omitted. The appender names in the list are attached
- to the designated logger. The forth argument of type
+ empty list if omitted. The appender names in the list are attached
+ to the designated logger. The fourth argument of type
<code>Boolean</code> is also optional and controls the <a
href="architecture.html#additivity">additivity flag</a>. If
omitted, it defaults to <code>null</code>.
</p>
- <p>For example, the following script set the level of the
+ <p>For example, the following script sets the level of the
"com.foo" logger to INFO.</p>
<pre class="prettyprint source">import static ch.qos.logback.classic.Level.INFO
@@ -219,8 +219,8 @@ root(DEBUG, ["FILE"])</pre>
<h3>• <span class="code">timestamp(String datePattern)</span></h3>
<p>The <code>timestamp()</code> method method returns a string
- corresponding to the current time formatted according to
- <code>datePattern</code> passed as parameter. The datePattern
+ corresponding to the current time formatted according to the
+ <code>datePattern</code> passed as a parameter. The datePattern
parameter should follow the conventions defined by <a
href="http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html">SimpleDateFormat</a>.
</p>
@@ -323,12 +323,12 @@ root(DEBUG, ["STDOUT"])</pre>
<h2>Internal DSL, i.e. it's all groovy baby!</h2>
<p>The <em>logback.groovy</em> is an internal DSL meaning that its
- contents are executed as a groovy script. Thus, all the usual
- groovy constructs such as class imports, GString, variable
+ contents are executed as a Groovy script. Thus, all the usual
+ Groovy constructs such as class imports, GString, variable
definitions, evaluation of ${..} expressions contained
- within strings (GStrings), if-else statements are all avaiable in
+ within strings (GStrings), if-else statements are all available in
logback.groovy files. In the following discussion, we will present
- typical uses of these groovy constructs in <em>logback.groovy</em>
+ typical uses of these Groovy constructs in <em>logback.groovy</em>
files.
</p>
@@ -336,7 +336,7 @@ root(DEBUG, ["STDOUT"])</pre>
<h3>Variable definitions and GStrings</h3>
<p>You can define variables anywhere within a
- <em>logback.groovy</em> files, then use the variable within a
+ <em>logback.groovy</em> file, then use the variable within a
GString. Here is an example.</p>
<pre class="prettyprint source">import ch.qos.logback.classic.encoder.PatternLayoutEncoder
@@ -427,8 +427,8 @@ appender("STDOUT", ConsoleAppender) {
<h3>Everything is context aware with a reference to the current
context</h3>
- <p>The execution of the <em>logback.grooy</em> script is done
- within a scope of a <a
+ <p>The execution of the <em>logback.groovy</em> script is done
+ within the scope of a <a
href="../xref/ch/qos/logback/core/spi/ContextAware.html">ContextAware</a>
object. Thus, the current context is always accessible using the
'<code>context</code>' variable and you can invoke
@@ -526,4 +526,4 @@ root(INFO, appenderList)</pre>
</div>
</body>
-</html>
\ No newline at end of file
+</html>
diff --git a/logback-site/src/site/pages/manual/index.html b/logback-site/src/site/pages/manual/index.html
index 5d0599a..66abd44 100644
--- a/logback-site/src/site/pages/manual/index.html
+++ b/logback-site/src/site/pages/manual/index.html
@@ -29,7 +29,7 @@
<p>
If you wish to print chapters in this document, we recommend
that you do so using <a
- href="http://www.getfirefox.com">Firefox 2</a>, with <em>Adapt to
+ href="http://www.getfirefox.com">Firefox 2+</a>, with <em>Adapt to
page size</em> enabled, or <a
href="http://www.opera.com">Opera</a>.
</p>
@@ -37,7 +37,7 @@
<p>The complete logback manual documents the latest version of
logback framework. In over 150 pages and dozens of concrete
- examples, it covers both basic and advanced logback features:
+ examples, it covers both basic and advanced logback features, including:
</p>
@@ -51,7 +51,7 @@
<li><p>layouts</p></li>
<li><p>filters</p></li>
<li><p>mapped diagnostic contexts</p></li>
- <li><p>joran, logback's configuration system</p></li>
+ <li><p>Joran, logback's configuration system</p></li>
</ul>
</div>
diff --git a/logback-site/src/site/pages/manual/introduction.html b/logback-site/src/site/pages/manual/introduction.html
index 481d609..287fb5a 100644
--- a/logback-site/src/site/pages/manual/introduction.html
+++ b/logback-site/src/site/pages/manual/introduction.html
@@ -34,7 +34,7 @@
much more complex entities in four months than they can
build.</em></p>
- <p>—FREDERIC P. BROOKS, JR., <em>The Mythical Man-Month</em></p>
+ <p>—FREDERICK P. BROOKS, JR., <em>The Mythical Man-Month</em></p>
</div>
@@ -44,13 +44,13 @@
<p>Logback is intended as a successor to the popular log4j
project. It was designed by Ceki Gülcü, log4j's
- founder. It builds upon a decade long experience gained in
+ founder. It builds upon a decade of experience gained in
designing industrial-strength logging systems. The resulting
- product, logback is faster with a smaller footprint than all
+ product logback is faster and has a smaller footprint than all
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 a few examples of useful
+ powerful event filtering. These are only a few examples of the 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
@@ -66,8 +66,8 @@
<a name="Requirements"></a>
<h3>Requirements</h3>
- <p>Logback-classic module requires the presence
- <em>slf4j-api.jar</em>, <em>logback-core.jar</em> in addition to
+ <p>Logback-classic module requires the presence of
+ <em>slf4j-api.jar</em> and <em>logback-core.jar</em> in addition to
<em>logback-classic.jar</em> on the classpath.
</p>
@@ -99,7 +99,7 @@ public class HelloWorld1 {
href="http://slf4j.org/api/org/slf4j/Logger.html"><code>Logger</code></a>
and <a
href="http://slf4j.org/api/org/slf4j/LoggerFactory.html"><code>LoggerFactory</code></a>
- classes defined in the SLF4J API, more specifically within the
+ classes defined in the SLF4J API, specifically within the
<code>org.slf4j</code> package.
</p>
@@ -117,8 +117,8 @@ public class HelloWorld1 {
<p>Note that the above example does not reference any logback
classes. In most cases, as far as logging is concerned, your
classes will only need to import SLF4J classes. Thus, the vast
- majority, if not all, of your classes will be cognizant of SLF4J
- API and oblivious to the existence of logback.
+ majority, if not all, of your classes will use the SLF4J
+ API and will be oblivious to the existence of logback.
</p>
@@ -182,7 +182,7 @@ public class HelloWorld2 {
policy, which is a basic <code>ConsoleAppender</code>. An
<code>Appender</code> is a class that can be seen as an output
destination. Appenders exist for many different destinations
- including the console, files, Syslog, TCP Socket, JMS and many
+ including the console, files, Syslog, TCP Sockets, JMS and many
more. Users can also easily create their own Appenders as
appropriate for their specific situation.
</p>
@@ -199,7 +199,7 @@ public class HelloWorld2 {
</p>
<p>Note that in the above example we have instructed logback to
- print its internal state by invoking
+ print its internal state by invoking the
<code>StatusPrinter.print()</code> method. Logback's internal status
information can be very useful in diagnosing logback-related
problems.
diff --git a/logback-site/src/site/pages/manual/jmxConfig.html b/logback-site/src/site/pages/manual/jmxConfig.html
index 7e7f7d9..c35bfb4 100644
--- a/logback-site/src/site/pages/manual/jmxConfig.html
+++ b/logback-site/src/site/pages/manual/jmxConfig.html
@@ -37,7 +37,7 @@
<p>If your server run on JDK 1.6 or later, then you can just
- invoke <code>jconsole</code> application on the commmand line and
+ invoke the <code>jconsole</code> application on the command line and
then connect to your server's MBeanServer. If you are running an
older JVM, then you should read the section on <a
href="#jmxEnablingServer">JMX enabling your server</a>.
@@ -76,23 +76,23 @@
<ul>
<li>Reload logback configuration using the default configuration
- file </li>
+ file.</li>
- <li>Reload the configuration with the specified URL</li>
- <li>Reload the configuration with the specified file</li>
+ <li>Reload the configuration with the specified URL.</li>
+ <li>Reload the configuration with the specified file.</li>
<li>Set the level of a specified logger. To set to null, pass
the string "null" as value.</li>
- <li>Get the level of a specified logger. Returned value can be
+ <li>Get the level of a specified logger. The returned value can be
null.</li>
<li>Get the <a href="architecture.html#effectiveLevel">effective
- level</a> of a specified logger</li>
+ level</a> of a specified logger.</li>
</ul>
<p><code>JMXConfigurator</code> exposes the list of existing
loggers and a status list as attributes.</p>
- <p>The status list can help you diagnose logbacks internal
+ <p>The status list can help you diagnose logback's internal
state.</p>
<img src="images/chapters/jmxConfigurator/statusList.gif" alt="statusList.gif"/>
@@ -106,12 +106,12 @@
from being garbage collected when it is stopped or re-deployed,
resulting in a severe memory leak.</p>
- <p>Thus, unless your application is standalone java application,
+ <p>Thus, unless your application is a standalone Java application,
you MUST unregister the <code>JMXConfigurator</code> instance from
the JVM's Mbeans server. Invoking the <code>reset</code>() method
of the appropriate <code>LoggerContext</code> will automatically
unregister any JMXConfigurator instance. A good place to reset the
- logger context is in the the <code>contextDestroyed</code>()
+ logger context is in the <code>contextDestroyed</code>()
method of a
<code>javax.servlet.ServletContextListener</code>. Here is sample
code:</p>
@@ -143,11 +143,11 @@ public class MyContextListener implements ServletContextListener {
</h2>
<p>If you deploy multiple web-applications in the same server,
- then, and assuming you have not overriden the default <a
- href="contextSelector.html">context selector</a>, and assuming you
+ and if you have not overridden the default <a
+ href="contextSelector.html">context selector</a>, and if you
have placed a copy of <em>logback-*.jar</em> and
<em>slf4j-api.jar</em> under the <em>WEB-INF/lib</em> folder of
- each web-application, by default each <code>JMXConfigurator</code>
+ each web-application, then by default each <code>JMXConfigurator</code>
instance will be registered under the same name, that is,
"ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator". In
other words, by default the various <code>JMXConfigurator</code>
@@ -180,14 +180,14 @@ public class MyContextListener implements ServletContextListener {
...
<configuration></pre>
- <p>In jconsole's MBeans panel, you would two distinct
+ <p>In jconsole's MBeans panel, you would see two distinct
<code>JMXConfigurator</code> instances:</p>
<img src="images/chapters/jmxConfigurator/multiple.gif" alt="multiple.gif"/>
<p>You may fully control the name under which JMXConfigurator is
- registered with MBeans server with the help of the "objectName"
- attribute of <code><jmxConfigurator></code> element.</p>
+ registered with an MBeans server with the help of the "objectName"
+ attribute of the <code><jmxConfigurator></code> element.</p>
<!-- ============ JMX enabling your server ================== -->
@@ -199,7 +199,7 @@ public class MyContextListener implements ServletContextListener {
<p>If your server runs with JDK 1.6 or later, your server should
be JMX enabled by default.</p>
- <p>For older JVMs, we suggest that you refer JMX-related
+ <p>For older JVMs, we suggest that you refer to the JMX-related
documentation of your web-server. Such documentation is available
for both <a
href="http://tomcat.apache.org/tomcat-6.0-doc/monitoring.html">Tomcat</a>
@@ -236,8 +236,8 @@ public class MyContextListener implements ServletContextListener {
</Get> </pre>
<p>If you wish to access the MBeans exposed by Jetty via the
- <code>jconsole</code> application, then you need start jetty after
- having set the "com.sun.management.jmxremote" java system
+ <code>jconsole</code> application, then you need to start Jetty after
+ having set the "com.sun.management.jmxremote" Java system
property.
</p>
@@ -246,8 +246,8 @@ public class MyContextListener implements ServletContextListener {
<p class="source">java <b>-Dcom.sun.management.jmxremote</b> -jar start.jar [config files]</p>
- <p>And if you wish to launch jetty as a Maven plugin, then you
- need set the "com.sun.management.jmxremote" system property via
+ <p>And if you wish to launch Jetty as a Maven plugin, then you
+ need to set the "com.sun.management.jmxremote" system property via
the <code>MAVEN_OPTS</code> shell variable:
</p>
@@ -266,10 +266,10 @@ mvn jetty:run</p>
<h4>MX4J with Jetty (tested under JDK 1.5 and 1.6)</h4>
- <p>Ig you wish to acces <code>JMXConfigurator</code> via MX4J's
+ <p>If you wish to access <code>JMXConfigurator</code> via MX4J's
HTTP interface and assuming you have already downloaded <a
href="http://mx4j.sourceforge.net/">MX4J</a>, you then need to
- modify the jetty configuration file discussed previously by adding
+ modify the Jetty configuration file discussed previously by adding
an instruction to set the management port.
</p>
@@ -294,7 +294,7 @@ mvn jetty:run</p>
class path.
</p>
- <p>If you are running jetty as a Maven plug-in, then you need to add
+ <p>If you are running Jetty as a Maven plug-in, then you need to add
<em>mx4j-tools</em> as a dependency.</p>
<pre class="prettyprint source"><plugin>
@@ -338,7 +338,7 @@ mvn jetty:run</p>
<p class="source">CATALINA_OPTS="-Dcom.sun.management.jmxremote"</p>
- <p>Once started with these options, Mbeans exposed by Tomcat as
+ <p>Once started with these options, MBeans exposed by Tomcat as
well logback's <code>JMXConfigurator</code> can be accessed with
<code>jconsole</code> by issuing the following command in a shell:
</p>
@@ -360,7 +360,7 @@ mvn jetty:run</p>
</p>
<p>Assuming you have already downloaded <a
- href="http://mx4j.sourceforge.net/">MX4J</a>, placethe
+ href="http://mx4j.sourceforge.net/">MX4J</a>, place the
<em>mx4j-tools.jar</em> file under the <em>$TOMCAT_HOME/bin/</em>
directory. Then, add the following lines to the
<em>$TOMCAT_HOME/bin/catalina.sh</em> configuration file:
diff --git a/logback-site/src/site/pages/manual/layouts.html b/logback-site/src/site/pages/manual/layouts.html
index 133f36e..3cb8333 100644
--- a/logback-site/src/site/pages/manual/layouts.html
+++ b/logback-site/src/site/pages/manual/layouts.html
@@ -68,7 +68,7 @@
<h2>Logback-classic</h2>
- <p>Logback-classic is wired to processes only events of type
+ <p>Logback-classic is wired to process only events of type
<a href="../xref/ch/qos/logback/classic/spi/ILoggingEvent.html">
<code>ch.qos.logback.classic.spi.ILoggingEvent</code></a>. This
fact will be apparent throughout this section.</p>
@@ -132,7 +132,7 @@ public class MySampleLayout extends LayoutBase<ILoggingEvent> {
instantiating a <code>StringBuffer</code>. It proceeds by adding
various fields of the event parameter. The Texan from Texas was
careful to print the formatted form of the message. This is
- significant in case one or more parameters were passed along with
+ significant if one or more parameters were passed along with
the logging request.
</p>
@@ -260,9 +260,9 @@ public class MySampleLayout2 extends LayoutBase<ILoggingEvent> {
needed to enable the configuration of a property. Note that the
<code>PrintThreadName</code> property is a boolean and not a
<code>String</code>. Configuration of logback components was
- covered in detail in the chapter on <a
- href="configuration.html">configuration</a>. The chapter <a
- href="onJoran.html">on joran</a> provides further detail. Here is
+ covered in detail in the <a
+ href="configuration.html">chapter on configuration</a>. The <a
+ href="onJoran.html">chapter on Joran</a> provides further detail. Here is
the configuration file tailor made for
<code>MySampleLayout2</code>.
</p>
@@ -297,7 +297,7 @@ public class MySampleLayout2 extends LayoutBase<ILoggingEvent> {
<code>PatternLayout</code></a>. As all layouts,
<code>PatternLayout</code> takes a logging event and returns a
<code>String</code>. However, this <code>String</code> can be
- customized at will by tweaking <code>PatternLayout</code>'s
+ customized by tweaking <code>PatternLayout</code>'s
conversion pattern.
</p>
@@ -317,7 +317,7 @@ public class MySampleLayout2 extends LayoutBase<ILoggingEvent> {
<p>As already mentioned on several occasions,
<code>FileAppender</code> and sub-classes expect an
- encoder. Consequently, when used in conjuction with
+ encoder. Consequently, when used in conjunction with
<code>FileAppender</code> or its subclasses a
<code>PatternLayout</code> must be wrapped within an
encoder. Given that the
@@ -371,7 +371,7 @@ public class PatternSample {
}</pre>
<p>In the above example, the conversion pattern is set to be
- <b>"%-5level [%thread]: %message%n"</b>. A synopssis of conversion
+ <b>"%-5level [%thread]: %message%n"</b>. A synopsis of conversion
word included in logback will be given shortly. Running
<code>PatternSample</code> application as:
</p>
@@ -491,7 +491,7 @@ WARN [main]: Message 2</p>
</tr>
</table>
- <p>Please note that the right most segment in a logger name
+ <p>Please note that the rightmost segment in a logger name
is never abbreviated, even if its length is longer than the
<em>length</em> option. Other segments may be shortened to
at most a single character but are never removed.</p>
@@ -511,14 +511,14 @@ WARN [main]: Message 2</p>
</p>
<p>Just like the <em>%logger</em> conversion word above,
- this conversion admits an integer as an option to shorten
+ this conversion takes an integer as an option to shorten
the class name. Zero carries special meaning and will cause
the simple class name to be printed without the package name
prefix. By default the class name is printed in full.
</p>
<p>Generating the caller class information is not
- particularly fast. Thus, it's use should be avoided unless
+ particularly fast. Thus, its use should be avoided unless
execution speed is not an issue.
</p>
</td>
@@ -583,7 +583,7 @@ WARN [main]: Message 2</p>
<p>In addition to the date pattern, this converter admits a
second option as the timezone. Thus, the
'%date{HH:mm:ss.SSS,Australia/Perth} would print the time in
- the time zone of Perth Australia, the worlds most isolated
+ the time zone of Perth, Australia, the world's most isolated
city.
</p>
@@ -706,7 +706,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
</p>
<p>
Generating the method name is not particularly fast.
- Thus, it's use should be avoided unless
+ Thus, its use should be avoided unless
execution speed is not an issue.
</p>
</td>
@@ -780,7 +780,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
generated the logging event.
</p>
- <p>If <b>mdc</b> conversion word is followed by a key
+ <p>If the <b>mdc</b> conversion word is followed by a key
between braces, as in <b>%mdc{clientNumber}</b>, then the
value in the MDC corresponding to the key will be output.
</p>
@@ -858,7 +858,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
<p>This conversion word can also use evaluators to test
logging events against a given criterion before creating the
output. For example, using <b>%ex{full, EX_DISPLAY_EVAL}</b>
- will display the full stack trace of the exception, only if
+ will display the full stack trace of the exception only if
the evaluator called <em>EX_DISPLAY_EVAL</em> returns a
<b>negative</b> answer. Evaluators are described further
down in this document.
@@ -888,8 +888,8 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
<code>PatternLayout</code> will automatically add it as the
last conversion word, on account of the importance of stack
trace information. The $nopex conversion word can be
- substituted for %xThrowable, in case you do not wish stack
- trace information to be displayed. See also %nopex
+ substituted for %xThrowable, if you do not wish stack
+ trace information to be displayed. See also the %nopex
conversion word.
</p>
@@ -926,7 +926,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
the printed class packaging information to differ from the
real class packaging information. So, in the above example,
given that packaging data for the Wombat class is preceded
- by a tilde, it possible that the correct packaging data is
+ by a tilde, it is possible that the correct packaging data is
in reality [wombat.jar:1.7].
</p>
@@ -1041,7 +1041,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
<h2><a name="formatModifiers" href="#formatModifiers">Format
modifiers</a></h2>
- <p>By default the relevant information is output as is. However,
+ <p>By default the relevant information is output as-is. However,
with the aid of format modifiers it is possible to change the
minimum and maximum width and the justifications of each data
field.
@@ -1160,7 +1160,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
</table>
<p>The table below list examples for format modifier
- truncation. Please note that the brackets, i.e the pair of "[]"
+ truncation. Please note that the square brackets, i.e the pair of "[]"
characters, are not part of the output. They are used to delimit
the width of output.</p>
@@ -1282,7 +1282,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
needs to be escaped. Thus, "<b>(</b>%d [%thread]<b>\)</b>" is
equivalent to "<b>\(</b>%d [%thread]<b>\)</b>". But since it
is not easy to recall which parenthesis needs escaping and which
- doesn't necessarily, you can escape both so that they are
+ doesn't, you can escape both so that they are
interpreted as literals.
</p>
@@ -1303,8 +1303,8 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
the logging events to the console, displaying date, thread, level,
message and caller data. Given that extracting the caller data of
a logging event is on the expensive side, we will do so only when
- the logging request originates from a specific logger, and whose
- message contains a certain string. Thus, we make sure that only
+ the logging request originates from a specific logger, and when
+ the message contains a certain string. Thus, we make sure that only
specific logging requests will have their caller information
generated and displayed. In other cases, where the caller data is
superfluous, we will not penalize application performance.
@@ -1313,7 +1313,7 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
<p>Evaluators and in particular <em>evaluation expressions</em>
are presented in a <a
href="filters.html#evalutatorFilter">dedicated section of the
- chapter on filters</a> which you MUST read if you want use
+ chapter on filters</a> which you MUST read if you want to use
evaluators in any meaninful way. Also note that the examples below
are implicitly based on <code>JaninoEventEvaluator</code> which
requires the <a
@@ -1350,8 +1350,8 @@ Caller+2 at mainPackage.ConfigTester.main(ConfigTester.java:38)</pre>
</configuration></pre>
<p>The above evaluation expression matches events which emanate
- from logger with a name containing the string "chapters.layouts"
- and the message containing the string "who calls thee". Due to XML
+ from a logger with a name containing the string "chapters.layouts"
+ and the message contains the string "who calls thee". Due to XML
encoding rules, the & character cannot be written as is, and
needs to be escaped as &amp;.</p>
@@ -1444,12 +1444,11 @@ Caller+0 at chapters.layouts.CallerEvaluatorExample.main(CallerEvaluatorExampl
some specific exceptions.
</p>
- <p>The java code shown below creates three log requests, each with
- an exception. The second exception different from the others
- contains the string "do not display this" and conttrary to the
- others it is of type
+ <p>The Java code shown below creates three log requests, each with
+ an exception. The second exception is different from the others:
+ it contains the string "do not display this" and it is of type
<code>chapters.layouts.TestException</code>. As its message
- commands, let us now prevent the third exception from being
+ commands, let us now prevent the second exception from being
printed.</p>
<p><em>
@@ -1544,7 +1543,7 @@ java.lang.Exception: display
<p>Notice how the second log statement has no stack trace. We
- effectively supressed the stack trace for the
+ effectively suppressed the stack trace for the
<code>TextException</code>. The text between square brackets at
the end of each stack trace line is <a
href="#xThrowable">packaging information</a> discussed
@@ -1572,7 +1571,7 @@ java.lang.Exception: display
href="../xref/ch/qos/logback/classic/pattern/ClassicConverter.html">
<code>ClassicConverter</code></a> objects are responsible for
extracting information out of <code>ILoggingEvent</code> instances
- and producing a String. For example, the
+ and producing a String. For example,
<a href="../xref/ch/qos/logback/classic/pattern/LoggerConverter.html">
<code>LoggerConverter</code></a>, the converter underlying the
%logger conversion word, extracts the name of the logger from
@@ -1713,7 +1712,7 @@ public class MySampleConverter extends ClassicConverter {
or more generally by literal text. Each specifier found in the
pattern will result in a separate column. Likewise a separate
column will be generated for each block of literal text found in
- the pattern potentially wasting valuable real estate on your
+ the pattern, potentially wasting valuable real-estate on your
screen.</p>
<p>Here is simple but functional configuration file illustrating
@@ -1786,7 +1785,7 @@ public class MySampleConverter extends ClassicConverter {
<p>The presentation of the HTML created by <code>HTMLLayout</code>
is controlled through a Cascading Style Sheet (CSS). In the
absence of specific instructions, <code>HTMLLayout</code> will
- default to its internal CSS. However, your can instruct
+ default to its internal CSS. However, you can instruct
<code>HTMLLayout</code> to use an external CSS file. For this
purpose a <code>cssBuilder</code> element can be nested within a
<code><layout></code> element, as shown below.
@@ -1822,7 +1821,7 @@ public class MySampleConverter extends ClassicConverter {
<p>As the original XMLLayout in log4j version 1.2.15, XMLLayout in
- logback-classic admits two boolean properties, <span
+ logback-classic takes two boolean properties, <span
class="option">locationInfo</span> and <span
class="option">properties</span>. Setting <span
class="option">locationInfo</span> to true enables the inclusion
@@ -1860,7 +1859,7 @@ public class MySampleConverter extends ClassicConverter {
<h2>Writing your own Layout</h2>
<p>Writing a custom <code>Layout</code> for logback access is
- nearly identical to its sibling<code>Layout</code> in
+ nearly identical to its sibling <code>Layout</code> in
logback-classic.</p>
@@ -1870,7 +1869,7 @@ public class MySampleConverter extends ClassicConverter {
<p><a href="../xref/ch/qos/logback/access/PatternLayout.html">
<code>PatternLayout</code></a> in logback-access can be configured
- much in the same way as its classic counterpart. However it
+ in much the same way as its classic counterpart. However it
features additional conversion specifiers suited for logging
particular bits of information availalbe only in HTTP servlet
requests and HTTP servlet responses.
@@ -2111,7 +2110,7 @@ public class MySampleConverter extends ClassicConverter {
</tr>
</table>
- <p>Logback access' <code>PatternLayout</code> also recognize three keywords, which
+ <p>Logback access' <code>PatternLayout</code> also recognizes three keywords, which
act like shortcuts to a certain pattern.</p>
<table class="bodyTable">
diff --git a/logback-site/src/site/pages/manual/loggingSeparation.html b/logback-site/src/site/pages/manual/loggingSeparation.html
index 17f6b54..0be426c 100644
--- a/logback-site/src/site/pages/manual/loggingSeparation.html
+++ b/logback-site/src/site/pages/manual/loggingSeparation.html
@@ -52,7 +52,7 @@
<p>The chapter deals with a relatively difficult problem of
providing a separate logging environment for multiple applications
running on the same web or EJB container. In the remainder of this
- chapter the term "application" will be used to refer either a
+ chapter the term "application" will be used to refer to either a
web-application or a J2EE application interchangeably. In a
separated logging environment, each application sees a distinct
logback environment, so that the logback configuration of one
@@ -69,7 +69,7 @@
<h2><a name="easy" href="#easy">The simplest and easiest
approach</a></h2>
- <p>Assuming your container supports child first class loading,
+ <p>Assuming your container supports child-first class loading,
separation of logging can be accomplished by embedding a copy of
slf4j and logback jar files in each of your applications. For
web-applications, placing slf4j and logback jar files under the
@@ -189,7 +189,7 @@
file called <em>logback-kenobi.xml</em> as a <em>resource</em>
using the thread context class loader. Thus, for example for the
kenobi web-application, <em>logback-kenobi.xml</em> should be
- placed under the under the <em>WEB-INF/classes</em> folder.
+ placed under the <em>WEB-INF/classes</em> folder.
</p>
<p>If you wish to, you may specify a different configuration file
@@ -208,9 +208,9 @@
<env-entry-value>aFolder/my_config.xml</env-entry-value>
</env-entry></pre>
- <p>The <em>my_config.xml</em> should be placed under
- <em>WEB-INF/classes/aFolfer/</em>. The important point to remember
- is that the configuration is looked up as a java resource using
+ <p>The file <em>my_config.xml</em> should be placed under
+ <em>WEB-INF/classes/aFolder/</em>. The important point to remember
+ is that the configuration is looked up as a Java resource using
the current thread's context class loader.
</p>
@@ -258,11 +258,11 @@
<p>When <code>ContextJNDISelector</code> is active, each time a
logger is retrieved, a JNDI lookup must be performed. This can
negatively impact performance, especially if you are using
- non-static (aka instance) logger references. Logback ships with a
+ non-static (a.k.a. instance) logger references. Logback ships with a
servlet filter named <a
href="../xref/ch/qos/logback/classic/selector/servlet/LoggerContextFilter.html">LoggerContextFilter</a>,
specifically designed to avoid the JNDI lookup cost. It can
- be installed by adding the following lines to your applications
+ be installed by adding the following lines to your application's
web.xml file.</p>
<pre class="prettyprint source"><filter>
@@ -278,7 +278,7 @@
<code>LoggerContextFilter</code> will obtain the logger context
associated with the application and then place it in a
<code>ThreadLocal</code> variable. <code>ContextJNDISelector</code>
- will first check if the said <code>ThreadLocal</code> variable is
+ will first check if the <code>ThreadLocal</code> variable is
set. If it is set, then JNDI lookup will skipped. Note that at the
end of the http request, the <code>ThreadLocal</code> variable will
be nulled. Installing <code>LoggerContextFilter</code> improves
@@ -327,7 +327,7 @@
<code>LoggerFactory.getLogger()</code> will return a logger
belonging to a logger context associated with the calling/current
application. But if <code>Mustafar</code> has a static logger
- reference, then its logger will be attach to logger context of the
+ reference, then its logger will be attached to the logger context of the
application that calls it first. Thus,
<code>ContextJNDISelector</code> does not provide logging
separation in case of shared classes using static logger
@@ -385,8 +385,8 @@
<p>If kenobi and yoda are web-applications, then the above
- configuration will output yoda's logs output to <em>yoda.log</em>
- and kenobi's logs to <em>kenobi.log</em>, this even logs generated
+ configuration will output yoda's log output to <em>yoda.log</em>
+ and kenobi's logs to <em>kenobi.log</em>; this even works for logs generated
by static logger references located in shared classes.</p>
<p>You can try out the technique just described with the help of the
@@ -446,7 +446,7 @@ DEBUG ch.qos.starwars.shared.Mustafar <b>cn=yoda</b> - in foo()</p
two distinct logging contexts logging to the same file, in this
case <em>kenobi.log</em>. Each of these contexts reference
<code>FileAppender</code> instances, nested within distinct
- <code>SiftingAppender</code> instances, logging to the same
+ <code>SiftingAppender</code> instances, that are logging to the same
file. Although logging separation seems to function according to
our wishes, FileAppender instances cannot safely write to the same
file unless they enable <span class="option">prudent</span>
diff --git a/logback-site/src/site/pages/manual/mdc.html b/logback-site/src/site/pages/manual/mdc.html
index afdb15b..5522b3d 100644
--- a/logback-site/src/site/pages/manual/mdc.html
+++ b/logback-site/src/site/pages/manual/mdc.html
@@ -73,7 +73,7 @@ public class MDC {
//Get the context identified by the <code>key</code> parameter.
<b>public static String get(String key);</b>
- //Remove the the context identified by the <code>key</code> parameter.
+ //Remove the context identified by the <code>key</code> parameter.
<b>public static void remove(String key);</b>
//Clear all entries in the MDC.
@@ -116,7 +116,7 @@ import ch.qos.logback.core.ConsoleAppender;
public class SimpleMDC {
static public void main(String[] args) throws Exception {
- // You can put values in the MDC at any time. Before anything else
+ // You can put values in the MDC at any time. Before anything else
// we put the first name
MDC.put("first", "Dorothy");
@@ -642,8 +642,8 @@ public class UserServletFilter implements Filter {
<h2><a name="mis"
href="#mis"><code>MDCInsertingServletFilter</code></a></h2>
- <p>Within web-applications, it often proves helpful to know the
- hostname, request uri and user-agent associated with a given http
+ <p>Within web applications, it often proves helpful to know the
+ hostname, request uri and user-agent associated with a given HTTP
request. <a
href="../xref/ch/qos/logback/classic/helpers/MDCInsertingServletFilter.html"><code>MDCInsertingServletFilter</code></a>
inserts such data into the MDC under the following keys.
@@ -719,7 +719,7 @@ public class UserServletFilter implements Filter {
<url-pattern>/*</url-pattern>
</filter-mapping> </pre>
- <p><b>If your web-app has multiple filter, make sure that
+ <p><b>If your web-app has multiple filters, make sure that
<code>MDCInsertingServletFilter</code> is declared before other
filters.</b> For example, assuming the main processing in your
web-app is done in filter 'F', the MDC values set by
diff --git a/logback-site/src/site/pages/manual/migrationFromLog4j.html b/logback-site/src/site/pages/manual/migrationFromLog4j.html
index 6f44908..15e6727 100644
--- a/logback-site/src/site/pages/manual/migrationFromLog4j.html
+++ b/logback-site/src/site/pages/manual/migrationFromLog4j.html
@@ -51,23 +51,23 @@
closely related. The core components, such as loggers, appenders
and layouts exist in both frameworks and serve identical
purposes. Similarly, the most important internal data-structure,
- namely <code>LoggingEvent</code> exists in both frameworks with
- rather similar but non-identical implementations. Most notably, In
+ namely <code>LoggingEvent</code>, exists in both frameworks with
+ rather similar but non-identical implementations. Most notably, in
logback-classic <code>LoggingEvent</code> implements the
- <code>ILoggingEvent</code> interface. Most of the changes requried
+ <code>ILoggingEvent</code> interface. Most of the changes required
in migrating log4j components to logback-classic are related to
differences in implementation of the <code>LoggingEvent</code>
class. Rest assured, these differences are rather limited. If in
spite of your best efforts you are unable to migrate any given
log4j component to logback-classic, do post a question on the <a
href="../mailinglist.html">logback-dev mailing list</a>. A logback
- developper should be able to provide guidance.
+ developer should be able to provide guidance.
</p>
<h3>Migrating a log4j layout</h3>
- <p>Let us begin by migrating a hypothetcical and trivially simple
+ <p>Let us begin by migrating a hypothetical and trivially simple
log4j layout named <a
href="../xref/chapters/migrationFromLog4j/TrivialLog4jLayout.html">TrivialLog4jLayout</a>
which returns the message contained in a logging events as the
@@ -202,7 +202,7 @@ public class TrivialLogbackAppender extends AppenderBase<ILoggingEvent> {
<code>requiresLayout</code> method is not used in logback and can
be removed. In logback, the <code>stop</code>() method is the
equivalent of log4j's <code>close</code>() method. However,
- <code>AppenderBase</code> in logback-classic, contains an nop
+ <code>AppenderBase</code> in logback-classic, contains a nop
implementation for <code>stop</code> which is sufficient for the
purposes of this trivial appender.
</p>
diff --git a/logback-site/src/site/pages/manual/onJoran.html b/logback-site/src/site/pages/manual/onJoran.html
index 0060d72..2c6d5be 100644
--- a/logback-site/src/site/pages/manual/onJoran.html
+++ b/logback-site/src/site/pages/manual/onJoran.html
@@ -51,7 +51,7 @@
folder.
</p>
- <p>To install joran, simply <a href="../download.html">download</a>
+ <p>To install Joran, simply <a href="../download.html">download</a>
logback and add <em>logback-core-${version}.jar</em> to your
classpath.</p>
@@ -64,10 +64,10 @@
their properties are specified within the <em>ejb.xml</em>
file. Similarly, logback settings can be specified in a
configuration file, expressed in XML format. Annotations available
- in JDK 1.5 and heavily used in EJB 3.0 replace many of directives
- previously found in XML files. Joran also makes use of annonations
- but at a much smaller extent. Due to the dynamic nature of logback
- configuration data (compared to EJBs) Joran's use of annonations
+ in JDK 1.5 and heavily used in EJB 3.0 replace many directives
+ previously found in XML files. Joran also makes use of annotations
+ but to a much smaller extent. Due to the dynamic nature of logback
+ configuration data (compared to EJBs) Joran's use of annotations
is rather limited.
</p>
@@ -79,8 +79,8 @@
the configuration file changed. The modified code had to be
recompiled and redeployed. Just as importantly, the code of the
<code>DOMConfigurator</code> consisted of loops dealing with
- children elements containing many interspersed if/else
- statements. One could not help but notice that that particular
+ child elements containing many interspersed if/else
+ statements. One could not help but notice that this particular
code reeked of redundancy and duplication. The <a
href="http://jakarta.apache.org/commons/digester/">commons-digester
project</a> had shown us that it was possible to parse XML files
@@ -147,8 +147,8 @@
<p>A Joran pattern is essentially a string. There are two kind of
patterns, <em>exact</em> and <em>wildcard</em>. The pattern "a/b"
- can be used to match <code><b></code> element nested within a
- top-level <code><a></code> element. The "a/b" will not match
+ can be used to match a <code><b></code> element nested within a
+ top-level <code><a></code> element. The "a/b" pattern will not match
any other element, hence the <em>exact</em> match designation.</p>
<p>Wildcards can be used to match suffixes or prefixes. For
@@ -166,7 +166,7 @@
association of patterns. Actions extend the <a
href="../xref/ch/qos/logback/core/joran/action/Action.html"><code>Action</code></a>
class, consisting of the following abstract methods. Other methods
- have been omitted for berevity.
+ have been omitted for brevity.
</p>
@@ -200,8 +200,8 @@ public abstract class Action {
}</pre>
<p>Thus, every action must implement the <code>begin()</code> and
- <code>end()</code> methods. The implemetnation of the
- <code>body()</code> method being optional on account of the
+ <code>end()</code> methods. The implementation of the
+ <code>body()</code> method is optional on account of the
empty/nop implementation provided by <code>Action</code>.</p>
@@ -215,10 +215,10 @@ public abstract class Action {
<p>As mentioned above, Joran is built on top of the SAX API. As an
XML document is parsed, each element generates events corresponding
- to the start, body and end of each element. When a joran
+ to the start, body and end of each element. When a Joran
configurator receives these events, it will attempt to find in its
rule store an action corresponding to the <em>current
- pattern</em>.. For example, the current pattern for the start, body
+ pattern</em>. For example, the current pattern for the start, body
or end event of element <em>B</em> nested within a top-level
<em>A</em> element is "A/B". The current pattern is a data
structure maintained automatically by Joran as it receives and
@@ -226,7 +226,7 @@ public abstract class Action {
<p>When several rules match the current pattern, then exact
matches override suffix matches, and suffix matches overide prefix
- matches. For exact details of implementation, please see the <a
+ matches. For exact details of the implementation, please see the <a
href="../xref/ch/qos/logback/core/joran/spi/SimpleRuleStore.html">SimpleRuleStore</a>
class.
</p>
@@ -259,14 +259,14 @@ public abstract class Action {
trivial action called <a
href="../xref/chapters/onJoran/helloWorld/HelloWorldAction.html">
<code>HelloWorldAction</code></a> which prints "Hello World" on the
- console when it's <code>begin()</code> method is invoked. The
+ console when its <code>begin()</code> method is invoked. The
parsing of XML files is done by a configurator. For the purposes of
- this chapter, we have developped a very simple configurator called
+ this chapter, we have developed a very simple configurator called
<a
href="../xref/chapters/onJoran/SimpleConfigurator.html"><code>SimpleConfigurator</code></a>.
The <a
href="../xref/chapters/onJoran/helloWorld/HelloWorld.html"><code>HelloWorld</code></a>
- application brings all pieces together.
+ application brings all these pieces together:
</p>
<ul>
@@ -276,10 +276,10 @@ public abstract class Action {
<code>HelloWorldAction</code> instance</li>
<li>It creates a <code>SimpleConfigutator</code>, passing it the
aforementioned rules map</li>
- <li>it then invokes the <code>doConfigure</code> method of the
+ <li>It then invokes the <code>doConfigure</code> method of the
configurator, passing the designated XML file as parameter
</li>
- <li>as a last step, the accumulated Status message in the context,
+ <li>As a last step, the accumulated Status message in the context,
if any, are printed</li>
</ul>
@@ -294,7 +294,7 @@ public abstract class Action {
<p class="command">java chapters.onJoran.helloWorld.HelloWorld src/main/java/chapters/onJoran/helloWorld/hello.xml</p>
- <p>You are highly encourared to poke about this example, by adding
+ <p>You are highly encourared to poke about in this example, by adding
new rules on the rule store, modifying the XML document
(hello.xml) and adding new actions.
</p>
@@ -427,7 +427,7 @@ public abstract class Action {
will pop two previously pushed integers, i.e. 10 and 3, and compute
their product. It will push the result, i.e. 30, at the top of the
stack. At the very end, in reponse to the end event corresponding to
- the <;/computation> tag, the ComputationAction1 will print the
+ the </computation> tag, the ComputationAction1 will print the
object at the top of the stack. Thus, running:
</p>
@@ -491,7 +491,7 @@ public abstract class Action {
attaches the resulting object to the parent.
</p>
- <p>Joran supports similar capability in the form of implicit
+ <p>Joran supports a similar capability in the form of implicit
actions. Joran keeps a list of implicit actions which are applied if
no explicit pattern could match the current pattern. However,
applying an implicit action may not be always appropriate. Before
@@ -499,7 +499,7 @@ public abstract class Action {
whether it is appropriate in the current situation. Only if the
action replies in the affirmative does the Joran configurator invoke
the (implicit) action. Note that this extra step makes it possible
- to support multiple implicit actions for or possibly none, if no
+ to support multiple implicit actions or possibly none, if no
implicit action is appropriate for a given situation.
</p>
@@ -553,7 +553,7 @@ Element [abc] asked to be printed.
20:33:43,750 |-ERROR in c.q.l.c.joran.spi.Interpreter@<b>10:9</b> - no applicable action for [xyz], current pattern is [[foo][xyz]]</p>
<p>Given that <code>NOPAction</code> instance is explicitly
- associated with the "*/foo" pattern, <code>NOPActgion</code>'s
+ associated with the "*/foo" pattern, <code>NOPAction</code>'s
<code>begin()</code> and <code>end()</code> methods are invoked on
<foo> elements. <code>PrintMeImplicitAction</code> is never
triggered for any of the <foo> elements. For other elements,
@@ -582,20 +582,20 @@ Element [abc] asked to be printed.
</p>
<p><code>NestedBasicPropertyIA</code> is applicable for any property
- whose type, is a primitive type, or equivalent object type in the
- <code>java.lang</code> package, an enumeration type, or any type
+ whose type is a primitive type (or equivalent object type in the
+ <code>java.lang</code> package), an enumeration type, or any type
adhering to the "valueOf" convention. Such properties are said to
be <em>basic</em> or <em>simple</em>. A class is said to adhere to
the "valueOf" convention if it contains a static method named
<code>valueOf</code>() taking a <code>java.lang.String</code> as
parameter and returning an instance of the type in question. At
- present time, <a
+ present, the <a
href="../xref/ch/qos/logback/classic/Level.html"><code>Level</code></a>,
<a
href="../xref/ch/qos/logback/core/util/Duration.html"><code>Duration</code></a>
and <a
href="../xref/ch/qos/logback/core/util/FileSize.html"><code>FileSize</code></a>
- classes follow this convention..
+ classes follow this convention.
</p>
<p><code>NestedComplexPropertyIA</code> action is applicable, in the
@@ -619,21 +619,21 @@ Element [abc] asked to be printed.
<ol>
<li>there is an internal rule associating the parent object's
- property with a designated class,
+ property with a designated class
</li>
<li>the setter method contains a @DefaultClass attribute
- designating a given class,</li>
+ designating a given class</li>
- <li>the parameter type of the setter method is a contcrete class
- possessing a public constructor,
+ <li>the parameter type of the setter method is a concrete class
+ possessing a public constructor
</li>
</ol>
<h4><a name="defaultClassMapping"
href="#defaultClassMapping">Default class mapping</a></h4>
- <p>In logback-classic, there are a handful of inernal rules mapping
- parent class/property name couples to a default class. These are
+ <p>In logback-classic, there are a handful of internal rules mapping
+ parent class/property name pairs to a default class. These are
listed in the table below.</p>
<table class="bodyTable">
@@ -693,7 +693,7 @@ Element [abc] asked to be printed.
<p>Note that in addition to single simple properties or single
- complex properties, logback's implicit actions support collectons of
+ complex properties, logback's implicit actions support collections of
properties, be they simple or complex. Instead of a setter method,
the property is specified by an "adder" method.</p>
diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html
index 136af2a..dadd9f7 100644
--- a/logback-site/src/site/pages/news.html
+++ b/logback-site/src/site/pages/news.html
@@ -1515,8 +1515,8 @@ ALTER TABLE logging_event ADD arg3 VARCHAR(254);</pre>
<p> Version 0.2.5 of logback has been released. </p>
- <p>This release offers better documentation. With a number of
- correction mande in the short introduction to logback-classic.
+ <p>This release offers better documentation, with a number of
+ corrections made in the short introduction to logback-classic.
</p>
<hr width="80%" align="center" />
@@ -1526,7 +1526,7 @@ ALTER TABLE logging_event ADD arg3 VARCHAR(254);</pre>
<p>Version 0.2 of logback has been released.</p>
- <p>It offers better tests, a few more functionalities, and enhanced
+ <p>It offers better tests, some more functionality, and enhanced
documentation. We also improved the site design to make it simpler
and more efficient.
</p>
diff --git a/logback-site/src/site/pages/reasonsToSwitch.html b/logback-site/src/site/pages/reasonsToSwitch.html
index ed2bcd3..3e7592b 100644
--- a/logback-site/src/site/pages/reasonsToSwitch.html
+++ b/logback-site/src/site/pages/reasonsToSwitch.html
@@ -71,8 +71,8 @@
file. Most of the examples in the documentation use this XML
syntax. However, as of logback version 0.9.22, <a
href="manual/groovy.html">configuration files written in
- Groovy</a> are also supported. Compared to XML, groovy style
- configuration is more intuitive, consistent and have a much
+ Groovy</a> are also supported. Compared to XML, Groovy-style
+ configuration is more intuitive, consistent and has a much
shorter syntax.
</p>
@@ -83,7 +83,7 @@
logback.groovy</a>.
</p>
- <p>We also plan to support configration files written in
+ <p>We also plan to support configuration files written in
Scala.</p>
@@ -129,7 +129,7 @@
<p>Developers often need to juggle between several logback
configuration files targeting different environments such as
development, testing and production. These configuration files
- have substantial parts in common differing only in a few
+ have substantial parts in common, differing only in a few
places. To avoid duplication, logback supports <a
href="manual/configuration.html#conditional">conditional
processing of configuration files</a> with the help of
@@ -217,12 +217,12 @@ java.lang.Exception: 99 is invalid
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:417) [jetty-6.1.12.jar:6.1.12]
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) [jetty-6.1.12.jar:6.1.12]</pre>
- <p>From the above, you can recognize that the applicaiton is using
+ <p>From the above, you can recognize that the application is using
Struts version 1.2.9 and was deployed under jetty version
6.1.12. Thus, stack traces will quickly inform the reader about
the classes invervening in the exception but also the package and
package versions they belong to. When your customers send you a
- stack trace, as a developper you will no longer need to ask them
+ stack trace, as a developer you will no longer need to ask them
to send you information about the versions of packages they are
using. The information will be part of the stack trace. See <a
href="manual/layouts.html#xThrowable">"%xThrowable" conversion
@@ -245,7 +245,7 @@ java.lang.Exception: 99 is invalid
or <a
href="manual/appenders.html#SizeAndTimeBasedFNATP">SizeAndTimeBasedFNATP</a>,
you can control the maximum number of archived files. If your
- rolling policy calls for monthly rollover and you wish to keep 1
+ rolling policy calls for monthly rollover and you wish to keep one
year's worth of logs, simply set the <span
class="option">maxHistory</span> property to 12. Archived log
files older than 12 months will be automatically removed.
@@ -260,7 +260,7 @@ java.lang.Exception: 99 is invalid
logback distribution, integrates with Servlet containers such as
Jetty or Tomcat to provide rich and powerful HTTP-access log
functionality. Since logback-access was part of the initial
- design, all the logback-classic features you came love are
+ design, all the logback-classic features you love are
available in logback-access as well.</p>
<h3><a name="inSummary" href="#inSummary">In summary</a></h3>
@@ -273,4 +273,4 @@ java.lang.Exception: 99 is invalid
</div>
</body>
-</html>
\ No newline at end of file
+</html>
diff --git a/logback-site/src/site/pages/recipes/index.html b/logback-site/src/site/pages/recipes/index.html
index 8c5f5a1..9988ee0 100644
--- a/logback-site/src/site/pages/recipes/index.html
+++ b/logback-site/src/site/pages/recipes/index.html
@@ -22,12 +22,12 @@
<h2>Real-world inspired logback recipes</h2>
<div>
- <p>Here is a list of logback-related recipes inpired by
+ <p>Here is a list of logback-related recipes inspired by
real-world use cases:</p>
<ul>
<li><p><a href="emailPerTransaction.html">Triggering an
- email containing the isoloated logs of selected
+ email containing the isolated logs of selected
transactions</a></p></li> </ul>
@@ -41,4 +41,3 @@
</div>
</body>
</html>
-
\ No newline at end of file
diff --git a/logback-site/src/site/pages/repos.html b/logback-site/src/site/pages/repos.html
index 22f323c..7a1e2e2 100644
--- a/logback-site/src/site/pages/repos.html
+++ b/logback-site/src/site/pages/repos.html
@@ -26,10 +26,10 @@
<p>We store the project's source code in a revision control system
called Git. Developers have write access to the repository,
enabling them to make changes to the source code. Everyone else
- has read-access to the repository. Thus, anyone can check out
+ has read-access to the repository. Thus, anyone can check out the
latest development version of the software. Note that the latest
- version in the repository may not work as expected. It may even
- not compile. If you are looking for a stable release, then
+ version in the repository may not work as expected. It may not
+ even compile. If you are looking for a stable release, then
download an official distribution.
</p>
diff --git a/logback-site/src/site/pages/setup.html b/logback-site/src/site/pages/setup.html
index 2922563..7ec3047 100644
--- a/logback-site/src/site/pages/setup.html
+++ b/logback-site/src/site/pages/setup.html
@@ -66,7 +66,7 @@
<p>Please edit the script in order to adapt the <em>LB_HOME</em> variable
to match your local environment.</p>
- <p>Please be aware that many examples will launch java classes
+ <p>Please be aware that many examples will launch Java classes
along with configuration files. To access these files by using the
same commands as written in the documentation, you will need to
issue the commands from within the
@@ -93,13 +93,13 @@
<h3><a name="janino" href="#janino">Evaluators and more
- specifically <code>JaninoEvantEvaluator</code> require
+ specifically <code>JaninoEventEvaluator</code> require
Janino</a></h3>
<p>The evaluator examples which are mostly based on
- <code>JaninoEvantEvaluator</code> require <a
+ <code>JaninoEventEvaluator</code> require <a
href="http://docs.codehaus.org/display/JANINO/Home"><b>Janino</b></a>
- version 2.5.10 or later. Once you downloaded Janino, you need to
+ version 2.5.10 or later. Once you have downloaded Janino, you need to
place <em>janino.jar</em> on your class path.</p>
-----------------------------------------------------------------------
Summary of changes:
logback-site/src/site/pages/access.html | 10 +-
logback-site/src/site/pages/bugreport.html | 2 +-
logback-site/src/site/pages/codes.html | 6 +-
logback-site/src/site/pages/consolePlugin.html | 33 +++---
logback-site/src/site/pages/demo.html | 102 ++++++++--------
logback-site/src/site/pages/documentation.html | 2 +-
logback-site/src/site/pages/download.html | 12 +-
logback-site/src/site/pages/faq.html | 14 +-
logback-site/src/site/pages/index.html | 2 +-
logback-site/src/site/pages/license.html | 10 +-
logback-site/src/site/pages/mailinglist.html | 8 +-
logback-site/src/site/pages/manual/appenders.html | 90 +++++++-------
.../src/site/pages/manual/architecture.html | 28 +++---
.../src/site/pages/manual/configuration.html | 122 ++++++++++----------
logback-site/src/site/pages/manual/encoders.html | 14 +-
logback-site/src/site/pages/manual/filters.html | 88 +++++++-------
logback-site/src/site/pages/manual/groovy.html | 52 ++++----
logback-site/src/site/pages/manual/index.html | 6 +-
.../src/site/pages/manual/introduction.html | 22 ++--
logback-site/src/site/pages/manual/jmxConfig.html | 50 ++++----
logback-site/src/site/pages/manual/layouts.html | 77 ++++++------
.../src/site/pages/manual/loggingSeparation.html | 26 ++--
logback-site/src/site/pages/manual/mdc.html | 10 +-
.../src/site/pages/manual/migrationFromLog4j.html | 12 +-
logback-site/src/site/pages/manual/onJoran.html | 72 ++++++------
logback-site/src/site/pages/news.html | 6 +-
logback-site/src/site/pages/reasonsToSwitch.html | 18 ++--
logback-site/src/site/pages/recipes/index.html | 5 +-
logback-site/src/site/pages/repos.html | 6 +-
logback-site/src/site/pages/setup.html | 8 +-
30 files changed, 455 insertions(+), 458 deletions(-)
hooks/post-receive
--
Logback: the generic, reliable, fast and flexible logging framework.
More information about the logback-dev
mailing list