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=4556c00a26f4aaee2d44d9d3f... http://github.com/ceki/logback/commit/4556c00a26f4aaee2d44d9d3fdff642297c32f... commit 4556c00a26f4aaee2d44d9d3fdff642297c32ffa Author: Ceki Gulcu <ceki@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.