August 2010 - logback-dev - mailman3.qos.ch

[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: (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

[JIRA] Created: (LBCORE-154) Use of default values in appender-refs
by David Harrigan (JIRA) 13 Oct '10

13 Oct '10

Use of default values in appender-refs -------------------------------------- Key: LBCORE-154 URL: http://jira.qos.ch/browse/LBCORE-154 Project: logback-core Issue Type: Improvement Components: Appender Environment: All Reporter: David Harrigan Assignee: Logback dev list This is referenced also here: http://old.nabble.com/Appender-Ref-Default-Value-to28605941.html Please can we have the ability to specify default values for appender-refs. I have a use case where we need to "bake-in" the appender during build-time. I can do this at the moment for logger level by bringing in a property file (called override.properties) that can reset the logging level (which is dependent on the deployment environment and other factors). Here is a little example: <property resource="override.properties" /> <logger name="bar.foo" level="${bar.foo.log.level:-info}" additivity="false"> <appender-ref ref="console"/> </logger> The bar.foo.log.level is defined in the override.properties file. The correct file gets inserted for each build type. I would like to do the following as well: <logger name="bar.foo" level="${bar.foo.log.level:-info}" additivity="false"> <appender-ref ref="${bar.foo.log.appender:-console}"/> </logger> So that I can tell the override where to log to (console for development or log file, or smtp, or jms, or db for other environments). This would be so neato if implemented :-) Thank you. -=david=- -- 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 8

[JIRA] Created: (LBCORE-159) AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application
by Ralph Goers (JIRA) 13 Oct '10

13 Oct '10

AppenderBase and UnsynchronizedAppenderBsae do not allow exceptions to percolate to the application --------------------------------------------------------------------------------------------------- Key: LBCORE-159 URL: http://jira.qos.ch/browse/LBCORE-159 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.24 Environment: All Reporter: Ralph Goers Assignee: Logback dev list When logging some events the application needs to be informed that the publishing of the event failed. Currently, AppenderBase and UnsynchronizedAppenderBase catch and handle all exceptions making it impossible to use any of the out-of-the box Logback appenders in these situations. This is particularly important when performing auditing and sending the events to a database, JMS queue, socket, etc. as the application would want to fail the current operation if it cannot be audited. -- 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 10

[JIRA] Created: (LBCORE-117) Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged
by Aaron Digulla (JIRA) 04 Oct '10

04 Oct '10

Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged ------------------------------------------------------------------------------------------------------------ Key: LBCORE-117 URL: http://jira.qos.ch/browse/LBCORE-117 Project: logback-core Issue Type: New Feature Components: Appender Reporter: Aaron Digulla Assignee: Logback dev list For many applications, it's not necessary to log at the levels DEBUG and TRACE all the time. In fact, we usually only do this to be able to debug ERROR events. It would be great if there was an appender that would only collect a configurable number of events internally until a message of level ERROR or above is logged. At this time, the appender should dump it's internal state to the log and reset the internal state. -- 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: (LBCLASSIC-222) Problem locating logback.xml from JEE deployment
by Rob Betgem (JIRA) 26 Aug '10

26 Aug '10

Problem locating logback.xml from JEE deployment ------------------------------------------------ Key: LBCLASSIC-222 URL: http://jira.qos.ch/browse/LBCLASSIC-222 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.21 Environment: Glassfish 2.1 Reporter: Rob Betgem Assignee: Logback dev list Logback seems to have a problem in locating the logback.xml configuration while being deployed as part of an EAR app on Glassfish. This incapability exists because the logback classic ContextInitializer class tries to locate the resource through a local classloader instead of the current thread context classloader. In some JEE app servers things are guaranteed to break if you try to locate resources with local classloaders. The findURLOfDefaultConfigurationFile method of the ch.qos.logback.classic.util.ContextInitializer class retrieves its current classloader with getClassLoader(). The current classloader returned during glassfish startup is not able to sense to full context of the deployed ear. At this startup stage it will return the ASURLClassloader instead of the needed EJBClassLoader. I fixed the problem by supplying the context class loader with Thread.currentThread().getContextClassLoader(). Could anybody please change this in one of the future releases. Thanks Rob -- 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

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.24-12-g91b5a95
by git-noreply＠pixie.qos.ch 25 Aug '10

25 Aug '10

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 91b5a954630b626d18bb9cf131490814e63a999d (commit) via 59827899f3ccd8ef62fb46e652ff7de0415780ed (commit) from b5da1126d5cb6b60b4d108e30f332a16b258a700 (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=91b5a954630b626d18bb9cf1… http://github.com/ceki/logback/commit/91b5a954630b626d18bb9cf131490814e63a9… commit 91b5a954630b626d18bb9cf131490814e63a999d Merge: 5982789 b5da112 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Aug 25 22:22:45 2010 +0200 Merge branch 'master' of git.qos.ch:/logback http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=59827899f3ccd8ef62fb46e6… http://github.com/ceki/logback/commit/59827899f3ccd8ef62fb46e652ff7de041578… commit 59827899f3ccd8ef62fb46e652ff7de0415780ed Author: Ceki Gulcu <ceki(a)qos.ch> Date: Wed Aug 25 22:22:17 2010 +0200 - minor edits and typo fixes diff --git a/logback-site/src/site/pages/manual/architecture.html b/logback-site/src/site/pages/manual/architecture.html index 9b1fb85..3af7059 100644 --- a/logback-site/src/site/pages/manual/architecture.html +++ b/logback-site/src/site/pages/manual/architecture.html @@ -91,7 +91,7 @@ is, the space of all possible logging statements, is categorized according to some developer-chosen criteria. In logback-classic, this categorization is an inherent part of loggers. Every single - loggers is attached to a <code>LoggerContext</code> which is + logger is attached to a <code>LoggerContext</code> which is responsible for manufacturing loggers as well as arranging them in a tree like hierarchy. diff --git a/logback-site/src/site/pages/manual/configuration.html b/logback-site/src/site/pages/manual/configuration.html index 1a28588..15bfd2c 100644 --- a/logback-site/src/site/pages/manual/configuration.html +++ b/logback-site/src/site/pages/manual/configuration.html @@ -407,13 +407,13 @@ public class Foo { the said configuration file changes. In order to instruct logback-classic to scan for changes in its configuration file and to automatically re-configure itself set the scan atrribute of the + class="attr">scan attribute of the <code><configuration></code> element to true, as shown next. Example: Scanning for changes in configuration - file and automatic re-configuraion + file and automatic re-configuration (logback-examples/src/main/java/chapters/configuration/scan1.xml) View as .grovvy @@ -602,9 +602,9 @@ public class MyApp3 { Here is <a - href="../xref/chapters/configuration/AddStatusListenerApp.html">sample code</a> - to register an OnConsoleStatusListener instance with the - StatusManager. + href="../xref/chapters/configuration/AddStatusListenerApp.html">sample + code</a> to register an <code>OnConsoleStatusListener</code> + instance with the StatusManager. <pre class="prettyprint source"> LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); @@ -710,7 +710,7 @@ public class MyApp3 { <code><logger></code> element</a></h4> At this point should have at least some understanding of <a - href="architecture.html#effectiveLevel">level inherirance</a> and + href="architecture.html#effectiveLevel">level inheritance</a> and the <a href="architecture.html#basic_selection">basic selection rule</a>. Otherwise, and unless you are an egyptologist, logback configuration will be no more meaningful to you than ----------------------------------------------------------------------- Summary of changes: .../src/site/pages/manual/architecture.html | 2 +- .../src/site/pages/manual/configuration.html | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.24-10-gb5da112
by git-noreply＠pixie.qos.ch 24 Aug '10

24 Aug '10

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 b5da1126d5cb6b60b4d108e30f332a16b258a700 (commit) from b2feaf8b45a5d208817cacd6cbf4d8c333b0fe9f (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=b5da1126d5cb6b60b4d108e3… http://github.com/ceki/logback/commit/b5da1126d5cb6b60b4d108e30f332a16b258a… commit b5da1126d5cb6b60b4d108e30f332a16b258a700 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Aug 24 23:54:21 2010 +0200 added link to akka diff --git a/logback-site/src/site/pages/index.html b/logback-site/src/site/pages/index.html index db39018..f8e3d00 100644 --- a/logback-site/src/site/pages/index.html +++ b/logback-site/src/site/pages/index.html @@ -66,6 +66,7 @@ <tr> <td valign="top"> <ul> + <li><a href="http://doc.akkasource.org/logging">Akka</a></li> <li><a href="http://jackrabbit.apache.org/">Apache Jackrabbit</a></li> <li><a href="http://www.jfrog.org/products.php">Artifactory</a></li> <li><a href="http://cia.sourceforge.net/">Citizen Intelligence Agency</a></li> ----------------------------------------------------------------------- Summary of changes: logback-site/src/site/pages/index.html | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0