- logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-204) A logger's appenders are not cleared when configuring using XML configuration file (as the manual says)
by Richard Fearn (JIRA) 20 Apr '10

20 Apr '10

A logger's appenders are not cleared when configuring using XML configuration file (as the manual says) ------------------------------------------------------------------------------------------------------- Key: LBCLASSIC-204 URL: http://jira.qos.ch/browse/LBCLASSIC-204 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.15 Reporter: Richard Fearn Assignee: Logback dev list Priority: Minor The Logback manual says: "The <logger> element may contain zero or more <appender-ref> elements; each appender thus referenced is added to the named logger. It is important to keep mind that each named logger that is declared with a <logger> element first has all its appenders removed and only then are the referenced appenders attached to it. In particular, if there are no appender references, then the named logger will lose all its appenders. " However this doesn't seem to be the case. Our scenario is that we reset a context, configure it using one configuration file, then configure it using a second configuration file. This can be reproduced by configuring the same context with the same configuration file twice. The appenders added to a logger the first time are not cleared before adding them a second time, resulting in duplicate appenders. The latest version of LoggerAction and AppenderRefAction don't seem to have anything in them that would clear the appenders, either. -- 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-150) ViewStatusMessagesServletBase has a System.out.println() and should be removed
by Jeff Jensen (JIRA) 19 Apr '10

19 Apr '10

ViewStatusMessagesServletBase has a System.out.println() and should be removed ------------------------------------------------------------------------------ Key: LBCORE-150 URL: http://jira.qos.ch/browse/LBCORE-150 Project: logback-core Issue Type: Bug Affects Versions: 0.9.20 Reporter: Jeff Jensen Assignee: Logback dev list Priority: Minor It has the following line in the service method: {code} System.out.println("service called"); {code} Keeping the console clean from these types of app methods is really important to many organizations, including my current customer, . -- 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. v0.9.20-6-g157bc93
by git-noreply＠pixie.qos.ch 16 Apr '10

16 Apr '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 157bc935c2f939dc73137f1f01e1a1f36526f913 (commit) from 6e526ff11d650992626ea5ff20e7f0751c493789 (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=157bc935c2f939dc73137f1f… http://github.com/ceki/logback/commit/157bc935c2f939dc73137f1f01e1a1f36526f… commit 157bc935c2f939dc73137f1f01e1a1f36526f913 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Fri Apr 16 22:53:54 2010 +0200 identidied syncronization prroblem in SiftingAppenderBase as shown by http://jira.qos.ch/browse/LBCLASSIC-203 diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/ConcurrentSiftingTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/ConcurrentSiftingTest.java new file mode 100644 index 0000000..0400413 --- /dev/null +++ b/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/ConcurrentSiftingTest.java @@ -0,0 +1,25 @@ +/** + * Logback: the reliable, generic, fast and flexible logging framework. + * Copyright (C) 1999-2010, QOS.ch. All rights reserved. + * + * This program and the accompanying materials are dual-licensed under either + * the terms of the Eclipse Public License v1.0 as published by the Eclipse + * Foundation + * + * or (per the licensee's choosing) + * + * under the terms of the GNU Lesser General Public License version 2.1 as + * published by the Free Software Foundation. + */ +package ch.qos.logback.classic.issue.lbclassic203; + +import org.junit.Test; + + +public class ConcurrentSiftingTest { + + @Test + public void test() { + throw new IllegalStateException(""); + } +} diff --git a/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/LogbackRolloverTest.java b/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/LogbackRolloverTest.java new file mode 100644 index 0000000..cc5f86f --- /dev/null +++ b/logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/LogbackRolloverTest.java @@ -0,0 +1,67 @@ +package ch.qos.logback.classic.issue.lbclassic203; + +import java.util.Date; + +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +public class LogbackRolloverTest extends Thread { + private static Logger log = LoggerFactory + .getLogger(LogbackRolloverTest.class); + private static final int DEFAULT_THREAD_COUNT = 2; + private static int threadcount = DEFAULT_THREAD_COUNT; + + public static void main(String[] args) { + if (args.length > 0) { + try { + threadcount = Integer.parseInt(args[0]); + } catch (Exception e) { + System.out + .println("Usage: LogbackRolloverTest [<thread count>] (defaults to " + + DEFAULT_THREAD_COUNT + " threads)"); + System.exit(1); + } + } + System.out.println("Logging from " + threadcount + + (threadcount == 1 ? " thread" : " threads") + + " (optional thread count parameter defaults to " + + DEFAULT_THREAD_COUNT + ")"); + + for (int i = 0; i < threadcount; i++) { + new LogbackRolloverTest().start(); + } + } + + public void run() { + int count = 0; + while (true) { + doLog(count++); + } + } + + private void doLog(int count) { + log.debug("The current date is " + new Date() + " the count is " + count); + log.info("Info Message"); + log.warn("Warn Message"); + log.trace("Trace message"); + log.error("Error message"); + log.info("Info Message"); + log.warn("Warn Message"); + log.trace("Trace message"); + log.error("Error message"); + try { + throw new Exception("throwing exception " + count + + " to create a stack trace"); + } catch (Exception e) { + log.error("caught " + e.toString(), e); + } + if (count % 10 == 0) { + try { + Thread.sleep(500); + } catch (InterruptedException e) { + log.error("Thread interrupted: " + e.toString(), e); + } + } + + } +} diff --git a/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderTrackerImpl.java b/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderTrackerImpl.java index ca86f4c..4e388b2 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderTrackerImpl.java +++ b/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderTrackerImpl.java @@ -68,7 +68,6 @@ public class AppenderTrackerImpl<E> implements AppenderTracker<E> { lastCheck = now; while (head.value != null && isEntryStale(head,now)) { Appender<E> appender = head.value; - //System.out.println(" stopping "+appender); appender.stop(); removeHead(); } diff --git a/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java b/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java index c82ed9b..865f040 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java +++ b/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java @@ -14,8 +14,8 @@ package ch.qos.logback.core.sift; import ch.qos.logback.core.Appender; +import ch.qos.logback.core.AppenderBase; import ch.qos.logback.core.CoreConstants; -import ch.qos.logback.core.UnsynchronizedAppenderBase; import ch.qos.logback.core.helpers.NOPAppender; import ch.qos.logback.core.joran.spi.JoranException; @@ -29,7 +29,7 @@ import ch.qos.logback.core.joran.spi.JoranException; * @author Ceki Gulcu */ public abstract class SiftingAppenderBase<E> extends - UnsynchronizedAppenderBase<E> { + AppenderBase<E> { protected AppenderTracker<E> appenderTracker = new AppenderTrackerImpl<E>(); AppenderFactoryBase<E> appenderFactory; @@ -73,9 +73,8 @@ public abstract class SiftingAppenderBase<E> extends String discriminatingValue = discriminator.getDiscriminatingValue(event); long timestamp = getTimestamp(event); - + Appender<E> appender = appenderTracker.get(discriminatingValue, timestamp); - if (appender == null) { try { appender = appenderFactory.buildAppender(context, discriminatingValue); @@ -91,6 +90,7 @@ public abstract class SiftingAppenderBase<E> extends } } appenderTracker.stopStaleAppenders(timestamp); + appender.doAppend(event); } diff --git a/logback-site/src/site/pages/index.html b/logback-site/src/site/pages/index.html index 07760e2..3e79dd3 100644 --- a/logback-site/src/site/pages/index.html +++ b/logback-site/src/site/pages/index.html @@ -66,26 +66,28 @@ <tr> <td valign="top"> <ul> + <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> <li><a href="http://www.geomajas.org/">Geomajas</a></li> - <li><a href="http://www.gradle.org/">Gradle</a></li> - <li><a href="http://jmxmonitor.sourceforge.net/">JMX Monitor</a></li> - + <li><a href="http://www.gradle.org/">Gradle</a></li> + </ul> </td> <td> <ul> + <li><a href="http://jmxmonitor.sourceforge.net/">JMX Monitor</a></li> + <li><a href="http://www.opengda.org/">OpenGDA</a></li> <li><a href="http://code.google.com/p/openmeetings/">OpenMeetings</a></li> <li><a href="http://liftweb.net/">Lift</a></li> <li><a href="http://www.red5.org">Red5</a></li> - <li><a href="http://scalate.fusesource.org/">Scalate</a></li> - <li><a href="http://sonar.codehaus.org/">Sonar</a></li> </ul> </td> <td valign="top"> <ul> + <li><a href="http://scalate.fusesource.org/">Scalate</a></li> + <li><a href="http://sonar.codehaus.org/">Sonar</a></li> <li><a href="http://static.springsource.org/s2-dmserver/2.0.x/user-guide/htmlsingle/user…">SpringSource dm Server</a></li> ----------------------------------------------------------------------- Summary of changes: .../issue/lbclassic203/ConcurrentSiftingTest.java | 13 +++- .../issue/lbclassic203/LogbackRolloverTest.java | 67 ++++++++++++++++++++ .../qos/logback/core/sift/AppenderTrackerImpl.java | 1 - .../qos/logback/core/sift/SiftingAppenderBase.java | 8 +- logback-site/src/site/pages/index.html | 12 ++-- 5 files changed, 88 insertions(+), 13 deletions(-) copy logback-core/src/main/java/ch/qos/logback/core/joran/conditional/Condition.java => logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/ConcurrentSiftingTest.java (71%) create mode 100644 logback-classic/src/test/java/ch/qos/logback/classic/issue/lbclassic203/LogbackRolloverTest.java hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCORE-149) file appender that rolls on startup
by Joe Kearney (JIRA) 15 Apr '10

15 Apr '10

file appender that rolls on startup ----------------------------------- Key: LBCORE-149 URL: http://jira.qos.ch/browse/LBCORE-149 Project: logback-core Issue Type: New Feature Components: Appender, Rolling Reporter: Joe Kearney Assignee: Logback dev list I'd like a file appender that can roll to a new file on startup. Example: * file name myApp.%d{yyyy-MM-dd}.%i.log * if the process lasts the whole day, we get only one log file for that day, called myApp.2010-04-15.0.log * if the process is restarted, we get multiple files for that day, myApp.2010-04-15.0.log, myApp.2010-04-15.1.log, ... Currently, I believe that the best we can do with the out-of-the-box appenders/rollers is to either append to or overwrite a single file per day. -- 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] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Joe Kearney (JIRA) 15 Apr '10

15 Apr '10

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Joe Kearney commented on LBCORE-26: ----------------------------------- You're right, I misread the start of this jira, apologies. New one opened here: http://jira.qos.ch/browse/LBCORE-149 > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Ceki Gulcu > Priority: Critical > Fix For: 0.9.18 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- 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-41) Provide a way for localtime date pattern
by Andreas Sahlbach (JIRA) 15 Apr '10

15 Apr '10

Provide a way for localtime date pattern ---------------------------------------- Key: LBGENERAL-41 URL: http://jira.qos.ch/browse/LBGENERAL-41 Project: logback-general Issue Type: New Feature Reporter: Andreas Sahlbach Assignee: Logback dev list I am providing a client library for customers all over the world. The client library is using slf4j. It also comes with a preconfigured logback version that provides logging for the commandline interface of the library and as an example working logging solution for my client library. I am also providing an out-of-the-box working logback.xml configuration. I now would like to have a possibility to log the current local time of the client in the log file. I currently can only specify no time zone that defaults back to GMT which will for sure raise lots of support calls to me, because lots of my clients don't even know what GMT is nor how to spell it... But I also can't specify a specific time zone, because I am in Europe and some of my customers are in China, so that would be awkward for them, too. So please provide a way for me to log the current localtime of the running program. (without dynamic log configuration via xml please). Using a special timezone value or something. This would be great, thanks! -- 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] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Ceki Gulcu (JIRA) 15 Apr '10

15 Apr '10

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-26: ---------------------------------- Hi Joe, The behavior that you describe, that is RollingFileAppender and TimeBasedRollingPolicy rolling to the same file within the same period even after application restart, is absolutely correct. In other words, if the periodicity is one minute, if the application is restarted within the same minute, the expected and correct behavior is for the restarted application to log to the same file and rollover at the end of the said minute. You seem to require the restarted application to always log to a different file regardless of the current period but that is different than the subject of this issue. Please enter a *new* jira issue describing your requirements. > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Ceki Gulcu > Priority: Critical > Fix For: 0.9.18 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- 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] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Joe Kearney (JIRA) 15 Apr '10

15 Apr '10

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Joe Kearney commented on LBCORE-26: ----------------------------------- Using %d{yyyy-MM-dd_HHmm} in the file name makes no difference, logging is appended to the end of the file if the process runs twice during the same minute. > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Ceki Gulcu > Priority: Critical > Fix For: 0.9.18 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- 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] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Ceki Gulcu (JIRA) 14 Apr '10

14 Apr '10

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-26: ---------------------------------- The archived files are numbered by date. Usually %i is used for roll over triggered by file size. Instead of daily roll over, can you experiment with shorter periods, for example by the minute with the pattern $d{yyyy-MM-dd_HHmm}, and see what happens? > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Ceki Gulcu > Priority: Critical > Fix For: 0.9.18 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- 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] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Joe Kearney (JIRA) 14 Apr '10

14 Apr '10

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Joe Kearney commented on LBCORE-26: ----------------------------------- This appears to be still broken in 0.9.20. I tried using (similar to) the sample in comment above. Tried with and without append=true, it always writes to the same file. It troubles me slightly that there's no obvious way for logback to decide how to number the rolled files, other than just appending an index - there's no %i, and adding one throws IllegalArgumentException when configuring it. {{code}} <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>${user.home}/output/myApp.%d{yyyy-MM-dd}.log</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>INFO</level> </filter> <append>true</append> <encoder> <pattern>%-4relative [%thread] %-5level %logger{35} - %msg [%file : %line]%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration> {{code}} > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Ceki Gulcu > Priority: Critical > Fix For: 0.9.18 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- 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