December 2007 - logback-dev

[Bug 92] New: TimeBasedRollingPolicy will not rollover a log file, append logs to a old log file.
by bugzilla-daemon＠pixie.qos.ch 13 May '08

13 May '08

http://bugzilla.qos.ch/show_bug.cgi?id=92 Summary: TimeBasedRollingPolicy will not rollover a log file, append logs to a old log file. Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: critical Priority: P1 Component: Rolling AssignedTo: logback-dev(a)qos.ch ReportedBy: benbrand(a)mac.com 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); } -- 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 55] New: Implement AsyncAppender
by bugzilla-daemon＠pixie.qos.ch 22 Apr '08

22 Apr '08

http://bugzilla.qos.ch/show_bug.cgi?id=55 Summary: Implement AsyncAppender Product: logback-classic Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: enhancement Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: anders_wallgren(a)alum.mit.edu Being able to write log files in the background is a requirement for production deployments of anything we would write on top of logback. Bonus points for including a feature to periodically flush the output. -- 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 107] New: Specificy the config file to use as a System property
by bugzilla-daemon＠pixie.qos.ch 04 Apr '08

04 Apr '08

http://bugzilla.qos.ch/show_bug.cgi?id=107 Summary: Specificy the config file to use as a System property Product: logback-core Version: unspecified Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: tgraham(a)concordenergy.com I'd like to be able to specify the logger config file to use as a System property, something like: java -Dlogback.configuration=customConfig.xml This is a much cleaner way of controlling the config than by messing with the classpath. -- 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 6

[Bug 100] New: Serialization of objectArray in LoggingEvent does not always work
by bugzilla-daemon＠pixie.qos.ch 22 Mar '08

22 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=100 Summary: Serialization of objectArray in LoggingEvent does not always work Product: logback-classic Version: unspecified Platform: PC URL: http://www.qos.ch/pipermail/logback-dev/2007- September/002169.html OS/Version: Other Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: noreply.ceki(a)qos.ch I think this is happening: * Logback is sending a serialized LoggingEvent over the socket * the LoggingEvent has a reference to the foo.bar.Car instance * the Eclipse plugin receives the bytes over the wire and tries to deserialize the LoggingEvent, this fails because the foo.bar.Car class is not on the classpath. Resolution: I think the SocketAppender should only send the formattedMessage over the wire and not the argumentArray. In other words: argumentArray should be declared transient. Let's see what the LogBack developers think about that ... -- 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 19

[Bug 52] New: Unable to use <onMatch> in logback.xml
by bugzilla-daemon＠pixie.qos.ch 19 Mar '08

19 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=52 Summary: Unable to use <onMatch> in logback.xml Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: kenichi-qos(a)sysart.jp With logback-0.9.2, when logback.xml contains <onMatch> or <onMismatch> tag, the following error occurs: ERROR in ch.qos.logback.core.joran.spi.Interpreter@30ae41 - no applicable action for [onMatch], current pattern is [[configuration][appender][filter][onMatch]] ERROR in ch.qos.logback.core.joran.spi.Interpreter@30ae41 - no applicable action for [onMismatch], current pattern is [[configuration][appender][filter][onMismatch]] Since I can specify neither <onMatch> nor <onMismatch>, I am unable to make use of EvaluatorFilter, which is one of the reasons I'm considering to use logback over log4j. The cause of the problem is the two methods which have been added to ch.qos.logback.core.filter.AbstractMatcherFilter (Revision 1380): http://svn.qos.ch/viewvc/logback/trunk/logback-core/src/main/java/ch/qos/lo… Because the return type of the getter method differs from the parameter type of the setter method, java.beans.PropertyDescriptor for the properties (onMatch and onMismatch) obtained in ch.qos.logback.core.util.PropertySetter contain no writeMethod (null value, confirmed with jdb-1.6), making PropertySetter.canContainComponent return NOT_FOUND. -- 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

[Bug 8] New: The insertion of a percent symbol causes the Parser to crash
by bugzilla-daemon＠pixie.qos.ch 19 Mar '08

19 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=8 Summary: The insertion of a percent symbol causes the Parser to crash Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Pattern AssignedTo: logback-dev(a)qos.ch ReportedBy: noreply.sebastien(a)qos.ch When inserting the percent char twice, so that it appears in the PatternLayout output, a number format exception is thrown. It does not prevent from using normally the PatternLayout. trace: ERROR in ch.qos.logback.core.joran.spi.Interpreter@131f71a - Exception in Action for tag <layout>8:14 java.lang.NumberFormatException: For input string: "% %" java.lang.NumberFormatException: For input string: "% %" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Integer.parseInt(Integer.java:447) at java.lang.Integer.parseInt(Integer.java:497) at ch.qos.logback.core.pattern.FormatInfo.valueOf(FormatInfo.java:70) at ch.qos.logback.core.pattern.parser.Parser.T(Parser.java:84) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:51) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) at ch.qos.logback.core.pattern.parser.Parser.parse(Parser.java:31) at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:76) at ch.qos.logback.core.joran.action.AbstractLayoutAction.end(AbstractLayoutAction.java:75) at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:289) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:152) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:633) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:719) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:125) at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:101) at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:84) at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:77) at mainPackage.ConfigTester.main(ConfigTester.java:21) -- 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 83] New: Parser stops at ')'
by bugzilla-daemon＠pixie.qos.ch 13 Mar '08

13 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=83 Summary: Parser stops at ')' Product: logback-core Version: unspecified Platform: All OS/Version: All Status: NEW Severity: blocker Priority: P1 Component: Pattern AssignedTo: logback-dev(a)qos.ch ReportedBy: jel(a)linofee.org The Parser skips everything after incl. ')'. Try e.g. <Pattern>%date{HH:mm:ss,SSS} [%thread] %-5level (%file:%line) - %message%n</Pattern> and thus is completely useless. Bummer! -- 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 1

[Bug 109] New: NullPointerException in deserialized AccessEvent.
by bugzilla-daemon＠pixie.qos.ch 13 Mar '08

13 Mar '08

http://bugzilla.qos.ch/show_bug.cgi?id=109 Summary: NullPointerException in deserialized AccessEvent. Product: logback-access Version: unspecified Platform: All OS/Version: Windows Status: NEW Severity: major Priority: P1 Component: Other AssignedTo: logback-dev(a)qos.ch ReportedBy: joern(a)huxhorn.de The following methods throw NPE's in case of deserialized AccessEvents. They should instead retun null. getRequestHeaderNames() buildRequestHeaderMap() buildRequestParameterMap() getResponseHeader(String key) getResponseHeaderNameList() getRequestContent() getStatusCode() (possibly, wrong if condition) getContentLength() (possibly, wrong if condition) getResponseContent() (please check) -- 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 14

[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