[logback-dev] [GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. release_0.9.19-3-gce0e611
added by portage for gitosis-gentoo
git-noreply at pixie.qos.ch
Fri Mar 26 00:37:52 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 ce0e6110ca1550aaa14c571db5f17de9accb6214 (commit)
from 72c5de7d8d3fa05a4d0cccf1270cb0407f5f193a (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=ce0e6110ca1550aaa14c571db5f17de9accb6214
http://github.com/ceki/logback/commit/ce0e6110ca1550aaa14c571db5f17de9accb6214
commit ce0e6110ca1550aaa14c571db5f17de9accb6214
Author: Ceki Gulcu <ceki at qos.ch>
Date: Fri Mar 26 00:37:03 2010 +0100
- updating the docs on loggingSeparation
diff --git a/logback-classic/src/test/input/joran/encoderCharset.xml b/logback-classic/src/test/input/joran/encoderCharset.xml
new file mode 100644
index 0000000..2ffe366
--- /dev/null
+++ b/logback-classic/src/test/input/joran/encoderCharset.xml
@@ -0,0 +1,18 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE configuration>
+
+<configuration debug="true">
+
+ <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
+ <encoder>
+ <pattern>%d - %m%n</pattern>
+ <charset>UTF-8</charset>
+ </encoder>
+ </appender>
+
+ <root level="DEBUG">
+ <appender-ref ref="CONSOLE" />
+ </root>
+
+</configuration>
+
\ No newline at end of file
diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html
index 5b5bf09..8208a53 100644
--- a/logback-site/src/site/pages/manual/configuration.html
+++ b/logback-site/src/site/pages/manual/configuration.html
@@ -1413,12 +1413,37 @@ fileName=myApp.log
</appender>
<b class="green big"></included></b></pre>
- <p>The file to be included can be referenced as a file, as a URL or
- as a resource. To reference a file use the <span
- class="attr">file</span> attribute. To reference a URL use the <span
- class="attr">url</span> attribute. To reference a resource, use the
- <span class="attr">resource</span> attribute.
- </p>
+
+ <p>Again, if you have note already, please note the mandatory <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>
+
+ <ul>
+
+ <li><b>As a file:</b><br/> To include a file use the <span
+ class="attr">file</span> attribute. You can use relative paths but
+ note that the current directory is defined by the application and
+ is not necessarily related to the path of the configuration
+ file.</li>
+
+ <li><p><b>As a resource:</b><br/> To include a resource, i.e a
+ file found on the class path, use the <span
+ class="attr">resource</span> attribute.</p>
+
+ <pre class="prettyprint source"><include resource="includedConfig.xml"/></pre>
+
+ </li>
+
+ <li><p><b>As a URL:</b><br/> To include the contents of a URL use
+ the <span class="attr">url</span> attribute.</p>
+
+ <pre class="prettyprint source"><include url="http://some.host.com/includedConfig.xml"/></pre>
+
+ </li>
+ </ul>
+
<h3><a name="contextName" href="#contextName">Setting the context name</a></h3>
diff --git a/logback-site/src/site/pages/manual/loggingSeparation.html b/logback-site/src/site/pages/manual/loggingSeparation.html
index 78a2a9a..cd69a95 100644
--- a/logback-site/src/site/pages/manual/loggingSeparation.html
+++ b/logback-site/src/site/pages/manual/loggingSeparation.html
@@ -87,44 +87,19 @@
<p>Easy as pie.</p>
- <p>Well, not exactly. First, although most do, not all containers
- support child first class loading. Second, logging generated by
- shared libraries will not be separated. The common idiom for
- referencing a logger is via a static reference. For example,
- </p>
-
- <pre class="prettyprint source">public class Foo {
- <b>static</b> Logger logger = LoggerFactory.getLogger(Foo.class);
- ...
-}</pre>
-
- <p>Static references are both memory and CPU efficient. Only one
- logger reference is used for all instances of the class. Moreover,
- the logger instance is retrieved only once, when the class is
- loaded into memory. Static logger references are fine as long as
- they are used in classes loaded by different class
- loaders. However, when a class is loaded by a parent class loader
- common to multiple applications, then the shared class in question
- will be loaded once and for all applications. If the shared class
- contains a static logger reference, than the logger will be
- retrieved once, when the shared class is loaded into memory and
- initialized. Moreover, for the shared class to successfully load
- into memory, slf4j and logback classed must be resolvable by the
- parent class loader. This implies that slf4j and logback jar
- files must also be accessible to the parent class loader. Note
- that for this scenario to occur a class must be shared
- <em>and</em> use slf4j.
- </p>
-
- <p>However, if the container itself uses SLF4J and defaults to
- parent-first class loading, then you need context selectors in
- order to acheive logging separation. Read on.
+ <p>Well, not exactly. Sometimes you will be forced to place SLF4J
+ and logback artifacts in a place accessible from all applications,
+ typically because a shared library uses SLF4J. In that case, all
+ applications will share the same logging environment. There are
+ various other scenarios where a copy of SLF4J and logback
+ artifacts is necessarily placed at a spot where it can be seen by
+ all applications making logging separation by class loader
+ separation impossible. All hope is not lost. Please read on.
</p>
<h2><a name="contextSelectors" href="#contextSelectors">Context
Selectors</a></h2>
-
<p>Logback provides a mechanism for a single instance of SLF4J and
logback classes loaded into memory to provide multiple logger
contexts. When you write:
@@ -139,9 +114,9 @@
an instance of <a
href="../apidocs/ch/qos/logback/classic/selector/ContextSelector.html">ContextSelector</a>. Note
that <code>ContextSelector</code> implementations always return
- instances of the <code>LoggerContext</code> class. This class
- implements the <code>ILoggerFactory</code> interface. In other
- words, a context selector has the option to returning any
+ instances <code>LoggerContext</code>. This class implements the
+ <code>ILoggerFactory</code> interface. In other words, a context
+ selector has the option to returning any
<code>LoggerContext</code> instance it sees fit according to its
own criteria. Hence the name context <em>selector</em>.
</p>
@@ -174,7 +149,11 @@
based on data available via JNDI lookup. This approach leverages
JNDI data separation mandated by the J2EE specification. Thus, the
same environment variable can be set to carry a different value in
- different applications.
+ different applications. In other words, calling
+ <code>LoggerFactory.getLogger()</code> from different applications
+ will return a logger attached to a different logger context, even
+ if there is a single LoggerFactory class loaded into memory shared
+ by all applications. That's logging separation for you.
</p>
<p>To enable <code>ContextJNDISelector</code>, the
@@ -183,7 +162,8 @@
<p class="source">-Dlogback.ContextSelector=JNDI</p>
- <p>Note that JNDI is a convenient shorthand for
+ <p>Note that the value <code>JNDI</code> is a convenient shorthand
+ for
<code>ch.qos.logback.classic.selector.ContextJNDISelector</code>.</p>
<h3><a name="settingJNDIVariables"
@@ -300,7 +280,123 @@
collection of the web-application when it is stopped or
recycled.</p>
- <script src="../templates/footer.js" type="text/javascript"></script>
-</div>
-</body>
-</html>
+
+ <h2><a name="tamingStaticRefs" href="#tamingStaticRefs">Taming
+ static references in shared libraries</a></h2>
+
+ <p><code>ContextJNDISelector</code> works nicely to create logging
+ separation when SLF4J and logback artifacts are shared by all
+ applications. When <code>ContextJNDISelector</code> is active, each
+ call to <code>LoggerFactory.getLogger()</code> will return a logger
+ belonging to a logger context associated with the calling/current
+ application.</p>
+
+ <p>The common idiom for referencing a logger is via a static
+ reference. For example,
+ </p>
+
+ <pre class="prettyprint source">public class Foo {
+ <b>static</b> Logger logger = LoggerFactory.getLogger(Foo.class);
+ ...
+}</pre>
+
+ <p>Static logger references are both memory and CPU
+ efficient. Only one logger reference is used for all instances of
+ the class. Moreover, the logger instance is retrieved only once,
+ when the class is loaded into memory. If the host class belongs to
+ some application, say kenobi, then the static logger will be
+ attached to kenobi's logger context by virtue of
+ <code>ContextJNDISelector</code>. Similarly, if the host class
+ belongs to some other application, say yoda, then its static
+ logger reference will be attached to yoda's logger context, again
+ 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
+ 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
+ separation in case of shared classes using static logger
+ 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.
+ </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
+ href="appenders.html#SiftingAppender"><code>SiftingAppender</code></a>
+ separate logging using JNDI data as separation criteria.
+ </p>
+
+ <p>Logback ships with a discriminator called <a
+ href="../xref/ch/qos/logback/classic/sift/JNDIBasedContextDiscriminator.html">JNDIBasedContextDiscriminator</a>
+ which returns the name of the current logger context as computed
+ by <code>ContextJNDISelector</code>. The
+ <code>SiftingAppender</code> and
+ <code>JNDIBasedContextDiscriminator</code> combination will create
+ separate appenders for each web-application.
+ </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><b>${contextName}.log</b></file>
+ <encoder>
+ <pattern>%-50(%level %logger{35}) %contextName - %msg%n</pattern>
+ </encoder>
+ </appender>
+ </sift>
+ </appender>
+
+ <root level="DEBUG">
+ <appender-ref ref="SIFT" />
+ </root>
+</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>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>So are we done yet? Well, not quite.</p>
+
+
+ <script src="../templates/footer.js"
+ type="text/javascript"></script> </div>
+ </body> </html>
diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html
index 6945029..cf7678c 100644
--- a/logback-site/src/site/pages/news.html
+++ b/logback-site/src/site/pages/news.html
@@ -33,7 +33,7 @@
<p>Fixed issue related to charsets in
<code>LayoutWrappingEncoder</code> not being recognized in config
- files..</p>
+ files.</p>
-----------------------------------------------------------------------
Summary of changes:
.../joran/{simple2.xml => encoderCharset.xml} | 7 +-
.../src/site/pages/manual/configuration.html | 37 ++++-
.../src/site/pages/manual/loggingSeparation.html | 180 +++++++++++++++-----
logback-site/src/site/pages/news.html | 2 +-
4 files changed, 174 insertions(+), 52 deletions(-)
copy logback-classic/src/test/input/joran/{simple2.xml => encoderCharset.xml} (68%)
hooks/post-receive
--
Logback: the generic, reliable, fast and flexible logging framework.
More information about the logback-dev
mailing list