November 2009 - logback-dev

branch, master, updated. 61bfd0d0ba8d095ce395ab763f8047307a58c418
by git-noreply＠pixie.qos.ch 08 Nov '09

08 Nov '09

The branch, master has been updated via 61bfd0d0ba8d095ce395ab763f8047307a58c418 (commit) from e5c863712b04faf94fab7678f01081f424e03893 (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=61bfd0d0ba8d095ce395ab76… http://github.com/ceki/logback/commit/61bfd0d0ba8d095ce395ab763f8047307a58c… commit 61bfd0d0ba8d095ce395ab763f8047307a58c418 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 19:44:41 2009 +0100 applied patch supplied by Hugues Malphettes in LBCLASSIC-165 diff --git a/logback-classic/pom.xml b/logback-classic/pom.xml index 47dda97..26beab2 100644 --- a/logback-classic/pom.xml +++ b/logback-classic/pom.xml @@ -208,8 +208,7 @@ </executions> <configuration> <instructions> - <Export-Package>ch.qos.logback.classic.*</Export-Package> - <Export-Package>org.slf4j.impl;version=1.5.6</Export-Package> + <Export-Package>ch.qos.logback.classic*, org.slf4j.impl;version=1.5.6</Export-Package> <Import-Package> sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * diff --git a/logback-site/src/site/pages/news.html b/logback-site/src/site/pages/news.html index a0e1217..2efe00d 100644 --- a/logback-site/src/site/pages/news.html +++ b/logback-site/src/site/pages/news.html @@ -28,6 +28,16 @@ <hr width="80%" align="center" /> + <h3>13th of November 2009 - Release of version 0.9.18</h3> + + <p>Fixed Private-Package and Export-Package sections in + logback-classic.jar MANIFEST as reported in <a + href="http://jira.qos.ch/browse/LBCLASSIC-165">LBCLASSIC-165</a> + by applying the relavant patch supplied by Hugues Malphettes. + </p> + + <hr width="80%" align="center" /> + <h3>9th of August 2009 - Release of version 0.9.17</h3> <p><code>PackagingDataCalculator</code> now correctly deals with ----------------------------------------------------------------------- Summary of changes: logback-classic/pom.xml | 3 +-- logback-site/src/site/pages/news.html | 10 ++++++++++ 2 files changed, 11 insertions(+), 2 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. e5c863712b04faf94fab7678f01081f424e03893
by git-noreply＠pixie.qos.ch 08 Nov '09

08 Nov '09

The branch, master has been updated via e5c863712b04faf94fab7678f01081f424e03893 (commit) from 0ec1b9eeed802b86dbc791654eeefb59ec327e25 (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=e5c863712b04faf94fab7678… http://github.com/ceki/logback/commit/e5c863712b04faf94fab7678f01081f424e03… commit e5c863712b04faf94fab7678f01081f424e03893 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Sun Nov 8 19:15:58 2009 +0100 - added warm up runs to failing LoggingEventSerializationPerfTest diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java index 862fc18..fe25a2f 100644 --- a/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java +++ b/logback-classic/src/test/java/ch/qos/logback/classic/spi/LoggingEventSerializationPerfTest.java @@ -27,7 +27,7 @@ import org.slf4j.helpers.BogoPerf; import ch.qos.logback.classic.net.NOPOutputStream; import ch.qos.logback.classic.net.testObjectBuilders.Builder; import ch.qos.logback.classic.net.testObjectBuilders.LoggingEventWithParametersBuilder; -import ch.qos.logback.classic.net.testObjectBuilders.TrivialLoggingEventBuilder; +import ch.qos.logback.classic.net.testObjectBuilders.TrivialLoggingEventBuilder; import ch.qos.logback.core.CoreConstants; import ch.qos.logback.core.testUtil.Env; @@ -89,18 +89,17 @@ public class LoggingEventSerializationPerfTest { } TrivialLoggingEventBuilder builder = new TrivialLoggingEventBuilder(); - doLoop(builder, LOOP_LEN); - noos.reset(); - double avg = doLoop(builder, LOOP_LEN); noos.reset(); - avg += doLoop(builder, LOOP_LEN); noos.reset(); - avg += doLoop(builder, LOOP_LEN); - - avg = avg/3; + for (int i = 0; i < 3; i++) { + doLoop(builder, LOOP_LEN); + noos.reset(); + } + double rt = doLoop(builder, LOOP_LEN); + System.out + .println("avetage time per logging event " + rt + " nanoseconds"); - System.out.println("avetage time per logging event "+avg+" nanoseconds"); - - long averageSize = (long) (noos.size()/(LOOP_LEN)); - System.out.println("noos size "+noos.size()+ " average size="+averageSize); + long averageSize = (long) (noos.size() / (LOOP_LEN)); + System.out.println("noos size " + noos.size() + " average size=" + + averageSize); double averageSizeLimit = 60; assertTrue("average size " + averageSize + " should be less than " @@ -108,10 +107,9 @@ public class LoggingEventSerializationPerfTest { // the reference was computed on Orion (Ceki's computer) long referencePerf = 5000; - BogoPerf.assertDuration(avg, referencePerf, CoreConstants.REFERENCE_BIPS); + BogoPerf.assertDuration(rt, referencePerf, CoreConstants.REFERENCE_BIPS); } - - + @Test public void testPerformanceWithParameters() { if (Env.isLinux()) { @@ -119,19 +117,23 @@ public class LoggingEventSerializationPerfTest { } LoggingEventWithParametersBuilder builder = new LoggingEventWithParametersBuilder(); - doLoop(builder, LOOP_LEN); - noos.reset(); - double avg = doLoop(builder, LOOP_LEN); - long averageSize = (long) (noos.size()/(LOOP_LEN)); + // warm up + for (int i = 0; i < 3; i++) { + doLoop(builder, LOOP_LEN); + noos.reset(); + } + double rt = doLoop(builder, LOOP_LEN); + long averageSize = (long) (noos.size() / (LOOP_LEN)); + + System.out.println("noos size " + noos.size() + " average size=" + + averageSize); - System.out.println("noos size "+noos.size()+ " average size="+averageSize); - double averageSizeLimit = 160; assertTrue("averageSize " + averageSize + " should be less than " + averageSizeLimit, averageSizeLimit > averageSize); // the reference was computed on Orion (Ceki's computer) long referencePerf = 7000; - BogoPerf.assertDuration(avg, referencePerf, CoreConstants.REFERENCE_BIPS); + BogoPerf.assertDuration(rt, referencePerf, CoreConstants.REFERENCE_BIPS); } } ----------------------------------------------------------------------- Summary of changes: .../spi/LoggingEventSerializationPerfTest.java | 46 ++++++++++--------- 1 files changed, 24 insertions(+), 22 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

branch, master, updated. 0ec1b9eeed802b86dbc791654eeefb59ec327e25
by git-noreply＠pixie.qos.ch 06 Nov '09

06 Nov '09

The branch, master has been updated via 0ec1b9eeed802b86dbc791654eeefb59ec327e25 (commit) from 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b (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=0ec1b9eeed802b86dbc79165… http://github.com/ceki/logback/commit/0ec1b9eeed802b86dbc791654eeefb59ec327… commit 0ec1b9eeed802b86dbc791654eeefb59ec327e25 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Nov 6 20:01:08 2009 +0100 - applied patch corresponding to Charles' commit 54534d77268ae8a00f0848ddb916879c8820ba18 dated October 07, 2009 diff --git a/logback-site/src/site/pages/manual/appenders.html b/logback-site/src/site/pages/manual/appenders.html index 3051ea3..debc52e 100644 --- a/logback-site/src/site/pages/manual/appenders.html +++ b/logback-site/src/site/pages/manual/appenders.html @@ -315,7 +315,7 @@ public class ExitWoes1 { lc.reset(); // we want to override the default-config. WriterAppender<ILoggingEvent> writerAppender = new WriterAppender<ILoggingEvent>(); writerAppender.setContext(lc); - writerAppender.setLayout(new EchoLayout<<ILoggingEvent>()); + writerAppender.setLayout(new EchoLayout<ILoggingEvent>()); OutputStream os = new FileOutputStream("exitWoes1.log"); writerAppender.setWriter(new OutputStreamWriter(os)); @@ -348,7 +348,7 @@ public class ExitWoes1 { uses this statement and outputs a logging request. </p> - <p>The <code>WriterAppender</code> is the super class of three other + <p>The <code>WriterAppender</code> is the superclass of three other appenders, namely <code>ConsoleAppender</code>, <code>FileAppender</code> which in turn is the super class of <code>RollingFileAppender</code>. The next figure illustrates the @@ -480,7 +480,7 @@ public class ExitWoes1 { class="option">BufferedIO</span> to true automatically sets the <span class="option">ImmediateFlush</span> option to false. The name <span class="option">BufferedIO</span> is slightly - misleading because buffered IO is already supported by + misleading because buffered I/O is already supported by <code>OutputStreamWriter</code>. Setting <span class="option">BufferedIO</span> to true has the effect of buffering I/O as well as character to raw byte conversions, @@ -557,7 +557,7 @@ public class ExitWoes1 { </tr> </table> - <p>By default, <code>FileAppender</code> performs a flushes each + <p>By default, <code>FileAppender</code> performs a flush on each event, ensuring that events are immediately written to disk. Setting the <span class="option">ImmediateFlush</span> option to false can drastically reduce I/O activity by letting @@ -612,7 +612,7 @@ public class ExitWoes1 { </h3> <p>During the application development phase or in the case of - short-lived applications, e.g. batch applications, it is desriable + short-lived applications, e.g. batch applications, it is desirable to create a new log file at each new application launch. This is fairly easy to do with the help of the <code><timestamp></code> element. Here's an example.</p> @@ -763,8 +763,7 @@ public class ExitWoes1 { <ol> <li>In prudent mode, file compression is not supported nor allowed. (We can't have one JVM writing to a file while - another JVM is compressing it.) - </li> + another JVM is compressing it.) </li> <li>The <span class="option">File</span> property of <code>FileAppender</code> cannot be set and must be left @@ -1357,7 +1356,7 @@ public interface RollingPolicy extends LifeCycle { <p>Size and time based archiving supports cleaning of old archive files. You just need to specify the number of periods to preserve - within the <code><MaxHistory></code> element. When your + with the <code><MaxHistory></code> element. When your application is stopped and restarted, logging will continue at the correct location, i.e. at the largest index number for the current period. @@ -1475,7 +1474,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { which implements the <code>ILoggingEvent</code> interface. Nevertheless, remote logging is non-intrusive as far as the logging event is concerned. On the receiving end after - desrialization, the event can be logged as if it were generated + deserialization, the event can be logged as if it were generated 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> @@ -1675,7 +1674,7 @@ public interface TriggeringPolicy<E> extends LifeCycle { </p> <p>Allow us to repeat for emphasis that serialization of logging - events is not intrusive. A desrialized event carries the same + events is not intrusive. A deserialized event carries the same information as any other logging event. It can be manipulated as if it were generated locally; except that serialized logging events by default do not include caller data. Here is an example @@ -1944,8 +1943,8 @@ Context ctx = new InitialContext(env);</pre> store and forward messaging comes at a hefty price. In return for increased cost, JMS messaging provides decoupling of sender and receiver. As long as the JMS provider is reachable, messages will - eventually arrive at destination. However, what if the JMS server - is down or simply unreachable? + eventually arrive at the destination. However, what if the JMS + server is down or simply unreachable? </p> <p>According to the JMS specification, producers can mark a @@ -2431,8 +2430,8 @@ Context ctx = new InitialContext(env);</pre> <p>You can pass the required parameters on the command line:</p> -<div class="source"><pre>java -Dfrom=source(a)xyz.com -Dto=recipient(a)xyz.com - -DsmtpHost=some_smtp_host src/main/java/chapter4.mail.EMail 10000 chapter4/mail/mail2.xml +<div class="source"><pre>java -Dfrom=source(a)xyz.com -Dto=recipient(a)xyz.com -DsmtpHost=some_smtp_host \ + src/main/java/chapter4.mail.EMail 10000 chapter4/mail/mail2.xml </pre></div> <p>Be sure to replace with values as appropriate for your @@ -2464,7 +2463,7 @@ Context ctx = new InitialContext(env);</pre> "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 - honors the basic HTML table structure, ignores the internal-CSS + honors the basic HTML table structure, ignores the internal CSS formatting. Gmail supports inline CSS formatitng but since inline CSS would make the resulting output too voluminous, <code>HTMLLayout</code> does not use inline CSS. @@ -3175,9 +3174,9 @@ public class CounterBasedEvaluator extends ContextAwareBase implements EventEval </configuration></pre> <p>With this new configuration, sending 500 logging requests to - the aforementioned MySQL database around 0.5 seconds, for an - average time of 1 millisecond per request, i.e. equivalent to a - tenfold improvement in performance. + the aforementioned MySQL database takes around 0.5 seconds, for an + average of 1 millisecond per request, that is a tenfold + improvement in performance. </p> <h3><a name="SyslogAppender" @@ -3416,7 +3415,7 @@ logger.debug("Alice says hello"); </p> href="#WriteYourOwnAppender">Writing your own Appender</a></h3> - <p>You can easily write your appender by sub-classing + <p>You can easily write your appender by subclassing <code>AppenderBase</code>. It handles support for filters, status messages and other functionality shared by most appenders. The derived class only needs to implement one method, namely @@ -3506,8 +3505,8 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { <p>The <a href="../xref/chapter4/CountingConsoleAppender.html"><code>CountingConsoleAppender</code></a> - can be configured like any appender. See sample configuration - file + can be configured like any other appender. See sample + configuration file <em>logback-examples/src/main/java/chapter4/countingConsole.xml</em> for an example. </p> @@ -3531,7 +3530,7 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { entity by transmitting serialized <code>AccessEvent</code> objects over the wire. Remote logging is non-intrusive as far as the access event is concerned. On the receiving end after - desrialization, the event can be logged as if it were generated + deserialization, the event can be logged as if it were generated locally. </p> <p> @@ -3597,8 +3596,8 @@ public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { directory. There is a specific script for each of the most popular database systems. If the script for your particular type of database system is missing, it should be quite easy to write one, - taking as example existing scripts. If you send them to us, we - will gladly include missing scripts in future releases. + taking as example one of the existing scripts. You are encouraged + to contribute such missing scripts back to the project. </p> <p>The <em>access_event</em> table's fields are described below:</p> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/manual/appenders.html | 47 ++++++++++----------- 1 files changed, 23 insertions(+), 24 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-125) Typo in methodname of ch.qos.logback.core.ContextBase
by Joern Huxhorn (JIRA) 05 Nov '09

05 Nov '09

Typo in methodname of ch.qos.logback.core.ContextBase ----------------------------------------------------- Key: LBCORE-125 URL: http://jira.qos.ch/browse/LBCORE-125 Project: logback-core Issue Type: Improvement Affects Versions: 0.9.17 Reporter: Joern Huxhorn Assignee: Logback dev list getBithTime should be getBirthTime -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

branch, master, updated. 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b
by git-noreply＠pixie.qos.ch 05 Nov '09

05 Nov '09

The branch, master has been updated via 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b (commit) from 46070d291951284bb5ab647090b44f4aff4593b0 (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=0acd6c2cbb7b85bbd909411e… http://github.com/ceki/logback/commit/0acd6c2cbb7b85bbd909411e6ad470a5e0d3c… commit 0acd6c2cbb7b85bbd909411e6ad470a5e0d3c64b Author: Ceki Gulcu <ceki(a)qos.ch> Date: Thu Nov 5 11:02:35 2009 +0100 - changed url of logback config wizard diff --git a/logback-site/src/site/pages/download.html b/logback-site/src/site/pages/download.html index 5326635..8004509 100644 --- a/logback-site/src/site/pages/download.html +++ b/logback-site/src/site/pages/download.html @@ -61,7 +61,7 @@ <dl> <dt> <a - href="http://wizardforge.org/pc?action=showVersion&id=72">Configuration + href="http://wizardforge.org/pc?action=displayFlowchartVersionPublic&id=42">Configuration wizard</a> by Dirk Ooms </dt> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/download.html | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

JMX Triggered Rollover for RollingFileAppender
by Tom Liu 04 Nov '09

04 Nov '09

Hi logback dev, We use RollingFileAppender quite heavily and it works perfect for us in most cases. However, in some situation, we find the local file system we're logging to is almost full when our application is still running, so we want to trigger a rollover manually via jmx, which archives the log file to a networked file system. In this way, we can make some extra space on local file system and prevent losing logs. Would you like to consider adding jmx triggered rollover feature, which could work with all the built-in rolling policies (FixedWindowRollingPolicy and TimeBasedRollingPolicy) ? Is there any way to achieve jmx triggered rollover in logback at this moment? I've filed a jira here: http://jira.qos.ch/browse/LBCORE-124 Thanks in advance ! Best Regards, Tom

1 0

[JIRA] Created: (LBCORE-124) JMX Triggered Rollover for RollingFileAppender
by tomliliu (JIRA) 04 Nov '09

04 Nov '09

JMX Triggered Rollover for RollingFileAppender ---------------------------------------------- Key: LBCORE-124 URL: http://jira.qos.ch/browse/LBCORE-124 Project: logback-core Issue Type: New Feature Components: Rolling Affects Versions: 0.9.17 Reporter: tomliliu Assignee: Logback dev list Priority: Minor Hi logback dev, We use RollingFileAppender quite heavily and it works perfect for us in most cases. However, in some situation, we find the local file system we're logging to is almost full when our application is still running, so we want to trigger a rollover manually via jmx, which archives the log file to a networked file system. In this way, we can make some extra space on local file system and prevent losing logs. Would you like to consider adding jmx triggered rollover feature, which could work with all the built-in rolling policies (FixedWindowRollingPolicy and TimeBasedRollingPolicy) ? Is there any way to achieve jmx triggered rollover in logback at this moment? Thanks in advance! Best Regards, Tom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Created: (LBGENERAL-36) Logging of java.lang.reflect.Type[] only displays the first element
by Jeff Jensen (JIRA) 03 Nov '09

03 Nov '09

Logging of java.lang.reflect.Type[] only displays the first element ------------------------------------------------------------------- Key: LBGENERAL-36 URL: http://jira.qos.ch/browse/LBGENERAL-36 Project: logback-general Issue Type: Bug Affects Versions: 0.9.17 Environment: Windows 7 Reporter: Jeff Jensen Assignee: Logback dev list Logging of arrays typically works fine. I encountered a situation where Logback only displays the first element of the array. I created a test case to demonstrate. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 4

Logback extensibility design.
by Gabriele Contini 02 Nov '09

02 Nov '09

Hi, I was facing a problem with Logback (the one described here http://jira.qos.ch/browse/LBCLASSIC-166) and i tried to extend the design of logback to implement this new feature without modifing the existing code. I found only one pre-defined extension point: the ContextSelector mechanism. But however i turn around the problem i can't extend Logback functionality without modifying the library. I think a "base library" should be extensible to fit different user needs and not "blocked" to extensions. The problems i've found are the following: * In my opinion LoggerContext should be (where possible) changed into ILoggerFactory in ContextSelector interface. Thus allowing for user defined LoggerContext implementation to be plugged in. * Moreover LoggerContext.getLogger(String) shouldn't be final, allowing users to subclass the LoggerContext and provide their own loggers implementation. It should also return an instance of org.slf4j.Logger as defined in ILoggerFactory interface (and not an ch.qos.logback.classic.Logger that's final and unchangeable). * At this stage of my work i cant' understand if i'll need to subclass ch.qos.logback.classic.Logger or i can just implement a org.slf4j.Logger that forwards his calls to a ch.qos.logback.classic.Logger instance. Anyway I'm sure that my work would be easier if ch.qos.logback.classic.Logger is not final. Best regards. Gabriele Contini

1 0

[JIRA] Commented: (LBCLASSIC-87) LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++)
by Gabriele Contini (JIRA) 02 Nov '09

02 Nov '09

[ http://jira.qos.ch/browse/LBCLASSIC-87?page=com.atlassian.jira.plugin.syste… ] Gabriele Contini commented on LBCLASSIC-87: ------------------------------------------- Hello Ceki, In my opinion static logger references in shared libraries should be able to switch context (maybe based on MDC or Environment values). I opened a new jira issue as you suggested. Please refer to: LBCLASSIC-166. Best regards. Gabriele Contini > LoggerContextFilter is useless (org.slf4j.Loggerfactory bug ++) > --------------------------------------------------------------- > > Key: LBCLASSIC-87 > URL: http://jira.qos.ch/browse/LBCLASSIC-87 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Jens Elkner > Assignee: Logback dev list > > Since LoggerFactory obtains the LoggerContext to use in its static init stage, using a LoggerContextFilter as described in Chapter 8 is completely useless, since the JNDI selector is never consulted again. > Digging deeper on that issue reveals, that using a ContextJNDISelector (even if it would work) rarely leads to the intended behavior (e.g. webapp related logging), and is probably not thread safe wrt. common practice and intended logging. E.g. in tomcat we have two different cases: > a) each webapp provides its own slfj4*.jar as well as *logback*.jar > b) slfj4*.jar as well as *logback*.jar are shared via tomcat/common/lib or > tomcat/share/lib > c) a und b mixed > Well, to get things right, one can say case c) is unsupported ;-). > In case a) logback has its own playground, so using JNDI doesn't make sense at all, since the webapp/logback has its own playground - doesn't interfere with > other web apps since loaded via its dedicated classloader. > However case b) is a little bit more challenging. Here the LoggerFactory and other classes are !shared! between several webapps, since loading is delegated from the dedicated webapp classloader to the shared webapp classloader, which picks up everything in share/lib , common/lib. So right now in 0.9.7, even if one uses JNDISelector a per webapp logging is impossible: The first webapp, which asks for a LoggerFactory always wins! All other webapps, which ask later for a LoggerFactory.getLogger() will get a Logger from the LoggerContext associated with the first webapp, since the context is "cached", i.e. the JNDI selector gets never consulted again. > Assuming the LoggerFactory problem gets fixed by using e.g. > public static Logger getLogger(* *) { > return StaticLoggerBinder.SINGLETON.getLoggerFactory().getLogger(**); > } > there is still a problem wrt. common practice aka log* usage pattern and webapp shared classes, which can not be resolved by JNDI: Today most developer use something like: > public class XY { > private static [final] Logger log = LoggerFactory.getLogger(XY.class); > ... > } > That implies the same problem, as with the current LoggerFactory bug: The class gets the Logger from the context associated with the first webapp, which needs the shared class. And that's why all other webapps, which later need this class will use the the logger context of the first webapp. So e.g. if webapp A is configured to log to /var/log/a.log and another webapp B is configured to log to /var/log/b.log the loging output of shared classes will always go to /var/log/a.log if webapp used the classes in question first, no matter on which thread aka in which webapp the shared classes are used. > So even if LoggerFactory gets fixed, JNDI selector is of little use, if one wants to have a webapp dedicated log as soon as shared classes are involved. > The only way to solve the didcated webapp log problem a can think of, to introduce another level of indirection in the Logger.log* etc. method, which takes care of thread local settings and the settings of its parent threads (e.g. an application may start other threads, which do not inherit the thread local settings from the current thread ...). But this would probably influence the performance of logback in a rather negative way. > Another idea might be an architecture re-design: sharing Loggers would be no problem because of thread local AppenderContext soft ref, which points to an Appender in the global AppenderStore singleton ... > RFE: These problems should be reflected chapter 8 of the logback manual to avoid further confusion ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0