February 2008 - logback-dev

[Bug 118] New: Console appender stops working after using paramter logging
by bugzilla-daemon＠pixie.qos.ch 13 Mar '08

13 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=118 Summary: Console appender stops working after using paramter logging Product: Console Plugin Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: critical Priority: P1 Component: interface AssignedTo: logback-dev(a)qos.ch ReportedBy: graham(a)crazysquirrel.com I'm pretty new to LOGBack but I've come across what appears to be a fairly major failing in the Eclipse console plugin. The first time a parameter replacing log message is used the console plugin stops working and doesn't log any further messages. I haven't written a simplified test case yet but here are three lines from my code that reliably trigger the problem: //This line appears in the console pluging and the standard tomcat console logger.debug( "Loading foo: " + foo ); //Neither of these two lines appear in the console plugin but do appear in the //standard tomcat console logger.debug( "Loading foo {} bar {} for baz {}", new Object[]{ foo, bar, baz} ); logger.debug( "Loading bar: " + bar ); -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 8

[Bug 105] New: SocketAppenderBase - ObjectOutputStream is not closed in case of an IOException.
by bugzilla-daemon＠pixie.qos.ch 11 Mar '08

11 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=105 Summary: SocketAppenderBase - ObjectOutputStream is not closed in case of an IOException. Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P1 Component: Appender AssignedTo: logback-dev(a)qos.ch ReportedBy: joern(a)huxhorn.de I think this is the cause of "hanging connections" in case of webserver restarts that I sometimes experience in lumberjack. Anyway, the stream should be closed in case of exception. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 5

[Bug 64] New: Logback MDC context is not inherited by child threads.
by bugzilla-daemon＠pixie.qos.ch 04 Mar '08

04 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=64 Summary: Logback MDC context is not inherited by child threads. Product: logback-classic Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: bendis(a)bendis.cz As stated in the javadoc documentation, the ch.qos.logback.classic.MDC should be inherited by a child thread: "A child thread automatically inherits a copy of the mapped diagnostic context of its parent." But the context is NOT ihnerited by child threads - the context HashMap is stored in the ThreadLocal, not in the InheritableThreadLocal. Regards, Bendis -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 2

[Bug 127] New: LoggerComparator sorts incorrectly
by bugzilla-daemon＠pixie.qos.ch 04 Mar '08

04 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=127 Summary: LoggerComparator sorts incorrectly Product: logback-classic Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: mark_z(a)charter.net ch.qos.logback.classic.spi.LoggerComparator doesn't work as intended, because it is violating the symmetric property and contract of java.util.Comparator.compare(T, T). While Logger l1 is checked against LoggerContext.ROOT_NAME, Logger l2 also needs to be checked. Current implementation: public int compare(Logger l1, Logger l2) { if (l1.getName().equals(LoggerContext.ROOT_NAME)) { return -1; } return l1.getName().compareTo(l2.getName()); } Corrected implementation: public int compare(Logger l1, Logger l2) { if(l1.getName().equals(LoggerContext.ROOT_NAME)){ return -1; } if(l2.getName().equals(LoggerContext.ROOT_NAME)){ return 1; } return l1.getName().compareTo(l2.getName()); } -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 5

svn commit: r1622 - logback/trunk
by noreply.ceki＠qos.ch 29 Feb '08

29 Feb '08

Author: ceki Date: Fri Feb 29 19:05:49 2008 New Revision: 1622 Modified: logback/trunk/pom.xml Log: - use slf4j 1.5.0 Modified: logback/trunk/pom.xml ============================================================================== --- logback/trunk/pom.xml (original) +++ logback/trunk/pom.xml Fri Feb 29 19:05:49 2008 @@ -36,7 +36,7 @@ <properties>  - <slf4j.version>1.5.0-SNAPSHOT</slf4j.version> + <slf4j.version>1.5.0</slf4j.version> <consolePlugin.version>1.0.1</consolePlugin.version> <retrotranslator.verify>false</retrotranslator.verify> </properties>

1 0

[Bug 130] New: Errors are hard to find
by bugzilla-daemon＠pixie.qos.ch 29 Feb '08

29 Feb '08

http://bugzilla.qos.ch/show_bug.cgi?id=130 Summary: Errors are hard to find Product: logback-access Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: noreply.ceki(a)qos.ch Even small errors are hard to debug since there is no output shown by the requestLog implementations. It would be nice to access the Context statii thourgh a servlet or other means. Ex: an error in the Layout pattern results in no access logs without any other information -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 0

svn commit: r1621 - logback/trunk/logback-core/src/main/java/ch/qos/logback/core
by noreply.ceki＠qos.ch 29 Feb '08

29 Feb '08

Author: ceki Date: Fri Feb 29 17:19:37 2008 New Revision: 1621 Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java Log: - renamed ContextBase.getPropertyMap as ContextBase.getCopyOfPropertyMap Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java Fri Feb 29 17:19:37 2008 @@ -28,7 +28,7 @@ return sm; } - public Map<String, String> getPropertyMap() { + public Map<String, String> getCopyOfPropertyMap() { return new HashMap<String, String>(propertyMap); }

1 0

svn commit: r1620 - logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi
by noreply.ceki＠qos.ch 29 Feb '08

29 Feb '08

Author: ceki Date: Fri Feb 29 17:19:31 2008 New Revision: 1620 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextRemoteView.java Log: - renamed ContextBase.getPropertyMap as ContextBase.getCopyOfPropertyMap Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextRemoteView.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextRemoteView.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggerContextRemoteView.java Fri Feb 29 17:19:31 2008 @@ -38,7 +38,7 @@ public LoggerContextRemoteView(LoggerContext lc) { // this(lc.getName(), lc.getPropertyMap()); this.name = lc.getName(); - this.propertyMap = lc.getPropertyMap(); + this.propertyMap = lc.getCopyOfPropertyMap(); } // public LoggerContextRemoteView(String name, Map<String, String>

1 0

Property for each Logger
by Mirko Jahn 18 Feb '08

18 Feb '08

Hi, I am trying to apply a certain property (String) to a Logger in order to later (optionally) define a Filter and Layout based on that property, but I haven't found a (nice) way to do that with the standard API (SLF4J with LOGBack). I was thinking about providing an extension of the Logger, but that class is final so I am wondering how I can solve my problem without touching LOGBack code. Maybe I am better off in the user list, but after I wasn't sure what's the better place for that. Unfortunately, I can't use Markers, because the property is not thread based (but ClassLoader - bundle based). The only simple solution that crossed my mind was using a custom syntax for my logger name, like "my.custom.property:some.FQCN". My problem with this version is that I would change the naming convention of loggers, which I would like to avoid if possible. Thanks, Mirko

1 0

[Bug 128] New: Multiple applications sharing the same config file
by bugzilla-daemon＠pixie.qos.ch 17 Feb '08

17 Feb '08

http://bugzilla.qos.ch/show_bug.cgi?id=128 Summary: Multiple applications sharing the same config file Product: logback-classic Version: unspecified Platform: PC URL: http://marc.info/?t=120308330000003&r=1&w=2 OS/Version: Windows Status: NEW Severity: enhancement Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: noreply.ceki(a)qos.ch The idea is to have a number of applications (over 20) to share the same config file so that the log output goes to different files. -- Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.

1 3