[logback-dev] [GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, encoder, updated. v0.9.18-39-g576c162
added by portage for gitosis-gentoo
git-noreply at pixie.qos.ch
Mon Feb 22 14:40:14 CET 2010
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Logback: the generic, reliable, fast and flexible logging framework.".
The branch, encoder has been updated
via 576c1625cf8a8f431af78f0a90ba1d8bc7fb21bb (commit)
from 2d9abfae52400cf99ce88470cdf85fb45046b60e (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=576c1625cf8a8f431af78f0a90ba1d8bc7fb21bb
http://github.com/ceki/logback/commit/576c1625cf8a8f431af78f0a90ba1d8bc7fb21bb
commit 576c1625cf8a8f431af78f0a90ba1d8bc7fb21bb
Author: Ceki Gulcu <ceki at qos.ch>
Date: Mon Feb 22 14:37:56 2010 +0100
mentioning packaging data in stack traces
diff --git a/logback-site/src/site/pages/reasonsToSwitch.html b/logback-site/src/site/pages/reasonsToSwitch.html
index 26b0381..41b7153 100644
--- a/logback-site/src/site/pages/reasonsToSwitch.html
+++ b/logback-site/src/site/pages/reasonsToSwitch.html
@@ -30,8 +30,8 @@
<p>Based on our previous work done on log4j, logback internals
have been re-written to perform about ten times faster on certain
- critical execution paths. Not only do logback components are
- faster, they have a smaller memory footprint as well.</p>
+ critical execution paths. Not only are logback components faster,
+ they have a smaller memory footprint as well.</p>
<h3><a name="tdd" href="#tdd">Extensive battery of tests</a></h3>
@@ -69,9 +69,9 @@
href="manual/configuration.html#autoScan">automatically reload its
configuration file upon modification</a>. The scanning process is
both fast and safe as it does <em>not</em> involve the creation of
- a separate scanning-thread. This technical subtlety ensures that
- logback plays well within application servers and more generally
- within the JEE environment.</p>
+ a separate thread for scanning. This technical subtlety ensures
+ that logback plays well within application servers and more
+ generally within the JEE environment.</p>
<h3><a name="lilith" href="#lilith">Lilith</a></h3>
@@ -90,8 +90,8 @@
<code>RollingFileAppender</code>.
</p>
- <p>Logback's <code>FileAppender</code> all its sub-classes
- including <code>RollingFileAppender</code> can gracefully recover
+ <p>Logback's <code>FileAppender</code> and all its sub-classes,
+ including <code>RollingFileAppender</code>, can gracefully recover
from I/O failures. Thus, if a file server fails temporarily, you
no longer need to restart your application just to repair logging.
</p>
@@ -103,30 +103,30 @@
href="manual/filters.html">filtering capabilities</a> going much
further than what log4j has to offer. For example, let's assume
that you have a business-critical application deployed on a
- production server. Given the large volume of transactions,
- logging level is set to WARN so that only warnings and errors are
- logged. Now imagine that you are confronted with a bug that can be
- reproduced on the production system but remains elusive on the
- test platform due to unspecified differences between the two
- environments (production/testing).
+ production server. Given the large volume of transactions
+ processed, logging level is set to WARN so that only warnings and
+ errors are logged. Now imagine that you are confronted with a bug
+ that can be reproduced on the production system but remains
+ elusive on the test platform due to unspecified differences
+ between those two environments (production/testing).
</p>
<p>With log4j, your only choice is to lower the logging level to
DEBUG on the production system in an attempt to identify the
problem. Unfortunately, this will generate large volume of logging
data, making analysis difficult. More importantly, extensive
- logging can impact the performance of you application on the
+ logging can impact the performance of your application on the
production system.</p>
<p>With logback, you have the option of keeping logging at the
WARN level for all users except for the one user, say Alice, who
is responsible for identifying the problem. When Alice is logged
- on, she will be logging at level DEBUG while for other users
- logging will remain at WARN. This feat can be accomplished by
- adding 4 lines of XML to your configuration file. Search for
+ on, she will be logging at level DEBUG while other users can
+ continue to log at the WARN level. This feat can be accomplished
+ by adding 4 lines of XML to your configuration file. Search for
<code>MDCFilter</code> in the <a
- href="manual/filters.html#TurboFilter">relevant section</a> of
- the manual.
+ href="manual/filters.html#TurboFilter">relevant section</a> of the
+ manual.
</p>
@@ -135,7 +135,7 @@
<p><a
href="manual/appenders.html#SiftingAppender">SiftingAppender</a>
is an amazingly versatile appender. It can be used to separate (or
- sift) logging according to any given runtime attribute. For
+ sift) logging according to <b>any</b> given runtime attribute. For
example, <code>SiftingAppender</code> can separate logging events
according to user sessions, so that the logs generated by each
user go into distinct log files, one log file per user.
@@ -144,14 +144,50 @@
<h3><a name="compression" href="#compression">Automatic
compression of archives log files</a></h3>
- <p><a href="manual/appenders.html#RollingFileAppender">RollingFileAppender</a> can automatically
- compression archived log files during rollover. Compression always
- occurs asynchronously so that even for large log files your
- application is not blocked for the duration of the compression.
+ <p><a
+ href="manual/appenders.html#RollingFileAppender">RollingFileAppender</a>
+ can automatically compress archived log files during
+ rollover. Compression always occurs asynchronously so that even
+ for large log files, your application is not blocked for the
+ duration of the compression.
</p>
- <h3><a name="maxHistory" href="#maxHistory">Automatic erasing of
+ <h3><a name="packagingData" href="#packagingData">Stack traces
+ with packaging data</a>
+ </h3>
+
+ <p>When logback prints an exception, the stack trace will include
+ packaging data. Here is a sample stack trace generated by the <a
+ href="demo.html">logback-demo</a> web-application.</p>
+
+ <pre>14:28:48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 is not a valid value
+java.lang.Exception: 99 is invalid
+ at ch.qos.logback.demo.prime.PrimeAction.execute(PrimeAction.java:28) [classes/:na]
+ at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) [struts-1.2.9.jar:1.2.9]
+ at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) [struts-1.2.9.jar:1.2.9]
+ at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) [struts-1.2.9.jar:1.2.9]
+ at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar:6.1.12]
+ at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:502) [jetty-6.1.12.jar:6.1.12]
+ at ch.qos.logback.demo.UserServletFilter.doFilter(UserServletFilter.java:44) [classes/:na]
+ at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1115) [jetty-6.1.12.jar:6.1.12]
+ at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:361) [jetty-6.1.12.jar:6.1.12]
+ 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
+ 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
+ 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#conversionWord">"%xThrowable" conversion
+ word</a> for details.
+ </p>
+
+ <h3><a name="maxHistory" href="#maxHistory">Automatic erasure of
old log files</a></h3>
<p>By setting the <span class="option">MaxHistory</span> property
-----------------------------------------------------------------------
Summary of changes:
logback-site/src/site/pages/reasonsToSwitch.html | 86 +++++++++++++++------
1 files changed, 61 insertions(+), 25 deletions(-)
hooks/post-receive
--
Logback: the generic, reliable, fast and flexible logging framework.
More information about the logback-dev
mailing list