[logback-dev] [GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. release_0.9.19-4-g39d30d0
added by portage for gitosis-gentoo
git-noreply at pixie.qos.ch
Fri Mar 26 17:01:02 CET 2010
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Logback: the generic, reliable, fast and flexible logging framework.".
The branch, master has been updated
via 39d30d0f0028dfd75177a298231d086b4dddbb73 (commit)
from ce0e6110ca1550aaa14c571db5f17de9accb6214 (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=39d30d0f0028dfd75177a298231d086b4dddbb73
http://github.com/ceki/logback/commit/39d30d0f0028dfd75177a298231d086b4dddbb73
commit 39d30d0f0028dfd75177a298231d086b4dddbb73
Author: Ceki Gulcu <ceki at qos.ch>
Date: Fri Mar 26 16:59:57 2010 +0100
- fixed http://jira.qos.ch/browse/LBCLASSIC-200
- minor edits
diff --git a/logback-site/src/site/pages/manual/loggingSeparation.html b/logback-site/src/site/pages/manual/loggingSeparation.html
index cd69a95..04f7054 100644
--- a/logback-site/src/site/pages/manual/loggingSeparation.html
+++ b/logback-site/src/site/pages/manual/loggingSeparation.html
@@ -230,7 +230,7 @@
<p>When the web-application is recycled or shutdown, we strongly
recommend that the incumbent <code>LoggerContext</code> be closed
- so that it can be properly gargabe collected. Logback ships with a
+ so that it can be properly garbage collected. Logback ships with a
<code>ServletContextListener</code> called <a
href="../xref/ch/qos/logback/classic/selector/servlet/ContextDetachingSCL.html"><code>ContextDetachingSCL</code></a>,
designed specifically for detaching the
@@ -312,11 +312,12 @@
by virtue of <code>ContextJNDISelector</code>.
</p>
- <p>If a class, say Mustafar, belongs to a library shared by both
- kenobi and yoda, as long as Mustafar has non static loggers, each
- invocation of <code>LoggerFactory.getLogger()</code> will return a
- logger belonging to a logger context associated with the
- calling/current application. But if Mustafar has a static logger
+ <p>If a class, say <code>Mustafar</code>, belongs to a library
+ shared by both <em>kenobi</em> and <em>yoda</em>, as long as
+ <code>Mustafar</code> has non static loggers, each invocation of
+ <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
application that calls it first. Thus,
<code>ContextJNDISelector</code> does not provide logging
@@ -324,22 +325,21 @@
references. This corner case has eluded a solution for eons.</p>
-
<p>The only way to solve this issue transparently and perfectly
would be to introduce another level of indirection inside loggers
so that each logger-shell somehow delegated work to an inner
logger attached to the appropriate context. This approach would be
quite difficult to implement and would incur a significant
- computational overhead. It is not an approach logback developpers
- plan to pursue.
+ computational overhead. It is not an approach we plan to pursue.
</p>
-
- <p>One could trivially solve the "shared class static logger"
- problem by moving the shared classes inside the web-apps (unshare
- them). If unsharing is not possible, then let <a
+ <p>It goes without saying that one could trivially solve the
+ "shared class static logger" problem by moving the shared classes
+ inside the web-apps (unshare them). If unsharing is not possible,
+ then we can solicit the magical powers of <a
href="appenders.html#SiftingAppender"><code>SiftingAppender</code></a>
- separate logging using JNDI data as separation criteria.
+ in order to separate logging using JNDI data as separation
+ criteria.
</p>
<p>Logback ships with a discriminator called <a
@@ -363,7 +363,7 @@
<appender name="FILE-${contextName}" class="ch.qos.logback.core.FileAppender">
<file><b>${contextName}.log</b></file>
<encoder>
- <pattern>%-50(%level %logger{35}) %contextName - %msg%n</pattern>
+ <pattern>%-50(%level %logger{35}) cn=%contextName - %msg%n</pattern>
</encoder>
</appender>
</sift>
@@ -375,28 +375,111 @@
</configuration></pre>
- <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
- by static logger refences located in shared classes.</p>
+ <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
+ by static logger references located in shared classes.</p>
+
+ <p>You can try out the technique just described with the help of the
+ <a
+ href="http://github.com/ceki/logback-starwars">logback-starwars</a>
+ project.
+ </p>
+
+
+ <p>The above approach solves the logging separation problem but is
+ rather complex. It requires the proper installation of
+ <code>ContextJNDISelector</code> and mandates that appenders be
+ wrapped by <code>SiftingAppender</code> which is a non-trivial beast
+ in itself.
+ </p>
+
+ <p>Note that each logging context can be configured using the same
+ file or alternatively different files. The choice is up to
+ you. Instructing all contexts to use the same configuration file
+ is simpler as only one file has to be maintained. Maintaining a
+ distinct configuration file for each application is harder to
+ maintain but allows for more flexibility.</p>
+
+ <p>So are we done yet? Can we declare victory and go home? Well, not
+ quite.</p>
+
+ <p>Let's assume the web-application <code>yoda</code> is initialized
+ before <code>kenobi</code>. To initialize <code>yoda</code>, visit
+ <code>http://localhost:port/yoda/servlet</code> which will invoke
+ the <code>YodaServlet</code>. This servlet just says hello and logs
+ message before calling the <code>foo</code> method in
+ <code>Mustafar</code> which not-surprisingly logs a simple message
+ and returns.
+ </p>
+
+ <p>After <code>YodaServlet</code> is called, the contents of
+ <em>yoda.log</em> file should contain</p>
+
+ <pre class="source">DEBUG ch.qos.starwars.yoda.YodaServlet cn=yoda - in doGet()
+DEBUG ch.qos.starwars.shared.Mustafar cn=yoda - in foo()</pre>
+
+ <p>Note how both log entries are associated with the "yoda" context
+ name. At this stage and until the server stops, the
+ <code>ch.qos.starwars.shared.Mustafar</code> logger is attached to
+ the 'yoda' context and will remain so until the server is stopped.
+ </p>
+
+ <p>Visiting <code>http://localhost:port/kenobi/servlet</code> will
+ output the following in <em>kenobi.log</em>.</p>
+
+ <pre class="source">DEBUG c.qos.starwars.kenobi.KenobiServlet <b>cn=kenobi</b> - in doGet()
+DEBUG ch.qos.starwars.shared.Mustafar <b>cn=yoda</b> - in foo()</pre>
+
+ <p>Note that even if the
+ <code>ch.qos.starwars.shared.Mustafar</code> logger outputs to
+ <em>kenobi.log</em> it is still attached to 'yoda'. Thus, we have
+ 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
+ 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>
+ mode. Otherwise, the target file will be corrupted.</p>
+
+ <p>Here is the configuration file enabling prudent mode:</p>
+
+ <pre class="prettyprint source"><configuration>
+
+ <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
+
+ <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
+ <discriminator class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator">
+ <defaultValue>unknown</defaultValue>
+ </discriminator>
+ <sift>
+ <appender name="FILE-${contextName}" class="ch.qos.logback.core.FileAppender">
+ <file>${contextName}.log</file>
+ <b><prudent>true</prudent></b>
+ <encoder>
+ <pattern>%-50(%level %logger{35}) cn=%contextName - %msg%n</pattern>
+ </encoder>
+ </appender>
+ </sift>
+ </appender>
+
+ <root level="DEBUG">
+ <appender-ref ref="SIFT" />
+ </root>
+</configuration></pre>
- <p>The above approach solves the logging separation problem but is
- rather complex. It requires the proper installation of
- <code>ContextJNDISelector</code> and mandates that appenders be
- wrapped by <code>SiftingAppender</code> which is a non-trivial beast
- in itself.
- </p>
- <p>Note that each logging context can be confiured using the same
- file or alternatively different files. The choice is up to
- you. Instruicting all contexts to use the same configuiration file
- is simpler as only one file has to be maintained. Maintaining a
- distinct configuration file for each application is harder to
- maintain but allows for more flexibility.</p>
+ <p>If you were able to keep up with the discussion thus far and
+ have actually tried the logback-starwars examples, then you must be
+ truly obsessed with logging. You should seek <a
+ href="http://www.qos.ch/shop/products/professionalSupport">professional
+ help</a>.</p>
- <p>So are we done yet? Well, not quite.</p>
- <script src="../templates/footer.js"
- type="text/javascript"></script> </div>
- </body> </html>
+ <script src="../templates/footer.js"
+ type="text/javascript"></script> </div>
+
+ </body>
+</html>
diff --git a/logback-site/src/site/pages/reasonsToSwitch.html b/logback-site/src/site/pages/reasonsToSwitch.html
index 4889038..877887d 100644
--- a/logback-site/src/site/pages/reasonsToSwitch.html
+++ b/logback-site/src/site/pages/reasonsToSwitch.html
@@ -196,10 +196,10 @@ java.lang.Exception: 99 is invalid
</p>
- <h3><a name="maxHistory" href="#maxHistory">Automatic erasure of
+ <h3><a name="maxHistory" href="#maxHistory">Automatic removal of
old log archives</a></h3>
- <p>By setting the <span class="option">MaxHistory</span> property
+ <p>By setting the <span class="option">maxHistory</span> property
of <a
href="manual/appenders.html#TimeBasedRollingPolicy">TimeBasedRollingPolicy</a>
or <a
@@ -207,11 +207,10 @@ java.lang.Exception: 99 is invalid
you can control the maximum number of archived files. If your
rolling policy calls for monthly rollover and you wish to keep 1
year's worth of logs, simply set the <span
- class="option">MaxHistory</span> property to 12. Archived log
+ class="option">maxHistory</span> property to 12. Archived log
files older than 12 months will be automatically removed.
</p>
-
<h3><a name="inSummary" href="#inSummary">In summary</a></h3>
<p>We have listed a number of reasons for preferring logback over
-----------------------------------------------------------------------
Summary of changes:
.../src/site/pages/manual/loggingSeparation.html | 153 +++++++++++++++-----
logback-site/src/site/pages/reasonsToSwitch.html | 7 +-
2 files changed, 121 insertions(+), 39 deletions(-)
hooks/post-receive
--
Logback: the generic, reliable, fast and flexible logging framework.
More information about the logback-dev
mailing list