September 2010 - logback-dev

[JIRA] Created: (LBCLASSIC-113) Nullpointer
by Mathias Bogaert (JIRA) 23 Dec '10

23 Dec '10

Nullpointer ----------- Key: LBCLASSIC-113 URL: http://jira.qos.ch/browse/LBCLASSIC-113 Project: logback-classic Issue Type: Bug Components: Other Reporter: Mathias Bogaert Assignee: Logback dev list Priority: Critical java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:769) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:641) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:637) [logback-classic-0.9.15.jar:na] at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:198) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:905) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] Hibernate calls if ( log.isTraceEnabled() ). -- 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

3 3

[JIRA] Created: (LBACCESS-10) Servlet input stream gets corrupted
by Augusto (JIRA) 16 Nov '10

16 Nov '10

Servlet input stream gets corrupted ----------------------------------- Key: LBACCESS-10 URL: http://jira.qos.ch/browse/LBACCESS-10 Project: logback-access Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows 7 - java 1.6.0_16-b01 - Hightide 6.1H10 Windows 7 - java 1.6.0_16-b01 - Tomcat 6.0.16 Solaris 5.10 - java 1.6.0_16 - Hightide 6.1H10 Reporter: Augusto Assignee: Logback dev list The request.inputStream() is wrapped in a TeeServletInputStreamm but this class fails to pass all the data in the original input stream to the servlets. In my tests is passes properly between 4 and 8kb of data and later it just return zeros instead of the characters. I'm attaching a very simple webapp that writes the input stream of a POST request into a file to demonstrate the bug. -- 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

[JIRA] Created: (LBCORE-170) CyclicBufferTrackerImpl.setBufferSize doesn't modify the field
by peter royal (JIRA) 21 Oct '10

21 Oct '10

CyclicBufferTrackerImpl.setBufferSize doesn't modify the field -------------------------------------------------------------- Key: LBCORE-170 URL: http://jira.qos.ch/browse/LBCORE-170 Project: logback-core Issue Type: Bug Components: Other Affects Versions: 0.9.24 Reporter: peter royal Assignee: Logback dev list The setBufferSize method on CyclicBufferTrackerImpl doesn't actually modify the field, making it impossible to shrink the buffer. -- 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

4 7

[JIRA] Created: (LBACCESS-14) support groovy configuration in logback-access
by Sean McEligot (JIRA) 20 Oct '10

20 Oct '10

support groovy configuration in logback-access ---------------------------------------------- Key: LBACCESS-14 URL: http://jira.qos.ch/browse/LBACCESS-14 Project: logback-access Issue Type: New Feature Affects Versions: 0.9.24 Reporter: Sean McEligot Assignee: Logback dev list Priority: Minor Currently logback access only supports Joran (XML) configuration. When a groovy file is given an XML parser exception occurs. If the file ends in .groovy, the configuration should use the groovy interpreter instead of the XML Parser. -- 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

[JIRA] Created: (LBCLASSIC-130) Multiple resource warning is not appropriate for logback-test.xml
by Jon Vincent (JIRA) 20 Oct '10

20 Oct '10

Multiple resource warning is not appropriate for logback-test.xml ----------------------------------------------------------------- Key: LBCLASSIC-130 URL: http://jira.qos.ch/browse/LBCLASSIC-130 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.14, 0.9.15, 0.9.16 Reporter: Jon Vincent Assignee: Logback dev list Priority: Minor When LBCLASSIC-85 was fixed, it also applied to logback-test.xml. Unfortunately, some IDEs (such as Eclipse) include the test classpath for all modules in a multi-module project -- which means that it's nearly impossible to avoid having multiple logback-test.xml files on the classpath if one project depends on another when running tests in Eclipse. Every test in the project will therefore emit this warning when run from the IDE. Is it possible to have the ContextInitializer only emit this warning for logback.xml, and not logback-test.xml? This would avoid a spurious/unactionable warning for developers using Eclipse. -- 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

5 14

[JIRA] Created: (LBGENERAL-42) Lifecycle stop() method is never called
by Lieven Doclo (JIRA) 20 Oct '10

20 Oct '10

Lifecycle stop() method is never called --------------------------------------- Key: LBGENERAL-42 URL: http://jira.qos.ch/browse/LBGENERAL-42 Project: logback-general Issue Type: Bug Reporter: Lieven Doclo Assignee: Logback dev list Don't know whether this is intended behavior, but when for example an configuration is loaded, the Lifecycle start() method is called. However, when the VM exits, stop() is never called. So anything in there is never executed. I came across this when writing a Google Charts appender for Perf4J. -- 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

3 3

[JIRA] Created: (LBCLASSIC-223) Two tests fail in latest commit 74915053db48b5e803816f8d39237cd85293273f
by Joern Huxhorn (JIRA) 19 Oct '10

19 Oct '10

Two tests fail in latest commit 74915053db48b5e803816f8d39237cd85293273f ------------------------------------------------------------------------ Key: LBCLASSIC-223 URL: http://jira.qos.ch/browse/LBCLASSIC-223 Project: logback-classic Issue Type: Bug Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" Reporter: Joern Huxhorn Assignee: Logback dev list ch.qos.logback.classic.joran.conditional.ConditionalTest.conditionalConsoleApp_IF_THEN_True (from ConditionalTest) java.lang.AssertionError: at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertNotNull(Assert.java:524) at org.junit.Assert.assertNotNull(Assert.java:535) at ch.qos.logback.classic.joran.conditional.ConditionalTest.conditionalConsoleApp_IF_THEN_True(ConditionalTest.java:79) ch.qos.logback.classic.turbo.ReconfigureOnChangeTest.scan_lbclassic154 (from ReconfigureOnChangeTest) java.lang.AssertionError: effective=3, expected=4 at org.junit.Assert.fail(Assert.java:91) at org.junit.Assert.assertTrue(Assert.java:43) at ch.qos.logback.classic.turbo.ReconfigureOnChangeTest.verify(ReconfigureOnChangeTest.java:181) at ch.qos.logback.classic.turbo.ReconfigureOnChangeTest.scan_lbclassic154(ReconfigureOnChangeTest.java:163) The first one seems to fail always while the second one fails sometimes. -- 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 11

[JIRA] Created: (LBCORE-114) Lifecycle.stop is not called for policy objects
by Anders Wallgren (JIRA) 14 Oct '10

14 Oct '10

Lifecycle.stop is not called for policy objects ----------------------------------------------- Key: LBCORE-114 URL: http://jira.qos.ch/browse/LBCORE-114 Project: logback-core Issue Type: Bug Affects Versions: 0.9.17 Reporter: Anders Wallgren Assignee: Logback dev list TriggeringPolicy implements Lifecycle, and start is called during configuration. However, when the context is shut down, stop is not called. -- 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 1

[JIRA] Created: (LBCORE-164) SizeAndTimeBasedFNATP will overwrite previous logging files with index > 9 on restart app.
by Dieter Mueller (JIRA) 13 Oct '10

13 Oct '10

SizeAndTimeBasedFNATP will overwrite previous logging files with index > 9 on restart app. ------------------------------------------------------------------------------------------ Key: LBCORE-164 URL: http://jira.qos.ch/browse/LBCORE-164 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Environment: Windows XP, java jdk1.6.0_18 Reporter: Dieter Mueller Assignee: Logback dev list Configuration: <appender name="DebugLog" class="ch.qos.logback.core.rolling.RollingFileAppender">  <file>c:/log/debug.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>c:/log/debug-old-%d{yyyy-MM-dd}.%i.log</fileNamePattern> <maxHistory>3</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>10KB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> <encoder> <pattern>%date{ISO8601} %-5level [%thread] %logger{30}:%line - %msg%n</pattern> </encoder> </appender> Steps to reproduce: 1. Start the application 2. debug.log was created. 3. let run, until periodscounter reaches 10 or more (or prepare the files), e.g. c:\log\debug-old-2010-08-10.0.log c:\log\debug-old-2010-08-10.1.log c:\log\debug-old-2010-08-10.10.log c:\log\debug-old-2010-08-10.11.log c:\log\debug-old-2010-08-10.12.log c:\log\debug-old-2010-08-10.2.log c:\log\debug-old-2010-08-10.3.log c:\log\debug-old-2010-08-10.4.log c:\log\debug-old-2010-08-10.5.log c:\log\debug-old-2010-08-10.6.log c:\log\debug-old-2010-08-10.7.log c:\log\debug-old-2010-08-10.8.log c:\log\debug-old-2010-08-10.9.log 4. restart the application 5. log to base.log 6. yyyy-MM-dd.10.log was (re-)created on rollover, overwrite the previous yyyy-MM-dd.10.log. Logging messages are lost. It looks like the root cause is the (reversed) sorting via filenames in method ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP.computeCurrentPeriodsHighestCounterValue(String) FileFilterUtil.reverseSortFileArrayByName(matchingFileArray); currentPeriodsCounter = FileFilterUtil.extractCounter(matchingFileArray[0], stemRegex); because the input file array looks like: c:\log\debug-old-2010-08-10.0.log c:\log\debug-old-2010-08-10.1.log c:\log\debug-old-2010-08-10.10.log c:\log\debug-old-2010-08-10.11.log c:\log\debug-old-2010-08-10.12.log c:\log\debug-old-2010-08-10.2.log c:\log\debug-old-2010-08-10.3.log c:\log\debug-old-2010-08-10.4.log c:\log\debug-old-2010-08-10.5.log c:\log\debug-old-2010-08-10.6.log c:\log\debug-old-2010-08-10.7.log c:\log\debug-old-2010-08-10.8.log c:\log\debug-old-2010-08-10.9.log and in reversed order: c:\log\debug-old-2010-08-10.9.log c:\log\debug-old-2010-08-10.8.log c:\log\debug-old-2010-08-10.7.log c:\log\debug-old-2010-08-10.6.log c:\log\debug-old-2010-08-10.5.log c:\log\debug-old-2010-08-10.4.log c:\log\debug-old-2010-08-10.3.log c:\log\debug-old-2010-08-10.2.log c:\log\debug-old-2010-08-10.12.log c:\log\debug-old-2010-08-10.11.log c:\log\debug-old-2010-08-10.10.log c:\log\debug-old-2010-08-10.1.log c:\log\debug-old-2010-08-10.0.log then the wrong index 9 of the first file is used! Suggestion for solution: Get all indizes and use the highest. for example: void computeCurrentPeriodsHighestCounterValue(final String stemRegex) { File file = new File(getCurrentPeriodsFileNameWithoutCompressionSuffix()); File parentDir = file.getParentFile(); File[] matchingFileArray = FileFilterUtil .filesInFolderMatchingStemRegex(parentDir, stemRegex); if (matchingFileArray == null || matchingFileArray.length == 0) { currentPeriodsCounter = 0; return; } // FileFilterUtil.reverseSortFileArrayByName(matchingFileArray); // currentPeriodsCounter = FileFilterUtil.extractCounter(matchingFileArray[0], stemRegex); for (File logFile : matchingFileArray) { int aPeriodCounter = FileFilterUtil.extractCounter(logFile, stemRegex); if (aPeriodCounter > currentPeriodsCounter) { currentPeriodsCounter = aPeriodCounter; } } if (tbrp.getParentsRawFileProperty() != null) { currentPeriodsCounter++; } } -- 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 2

[JIRA] Created: (LBCLASSIC-216) java.lang.NullPointerException in ThrowableProxyUtil.java:42
by Luciano Canè (JIRA) 13 Oct '10

13 Oct '10

java.lang.NullPointerException in ThrowableProxyUtil.java:42 ------------------------------------------------------------ Key: LBCLASSIC-216 URL: http://jira.qos.ch/browse/LBCLASSIC-216 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.24 Environment: IDE WebSphere 6.1 , IBM JDK 1.5 Reporter: Luciano Canè Assignee: Logback dev list {code:title=test example} import org.slf4j.LoggerFactory; public class TestLogBack { public TestLogBack() { super(); } public static void main(String[] args) { TestLogBack test = new TestLogBack(); test.execute(); } private void execute() { org.slf4j.Logger logger = LoggerFactory.getLogger(TestLogBack.class); //test try { throw new TestLogBackException("Test: getStackTrace() return null"); //$NON-NLS-1$ } catch (Throwable t) { logger.error("Messaggio di Test di {}", t.getMessage(), t); //$NON-NLS-1$ } } class TestLogBackException extends Exception { private static final long serialVersionUID = 1L; public TestLogBackException(String message) { super(message); } @Override public StackTraceElement[] getStackTrace() { return null; } } } {code} {code:title=exception stack trace} Exception in thread "main" java.lang.NullPointerException at ch.qos.logback.classic.spi.ThrowableProxyUtil.steArrayToStepArray(ThrowableProxyUtil.java:42) at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:35) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:123) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:462) at ch.qos.logback.classic.Logger.error(Logger.java:580) at z_prove.logback.TestLogBack.execute(TestLogBack.java:28) at z_prove.logback.TestLogBack.main(TestLogBack.java:13) {code} -- 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

3 7