- logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-127) RollingFileAppender does not roll the files in SimpleSocketServer
by Rick Janda (JIRA) 15 May '09

15 May '09

RollingFileAppender does not roll the files in SimpleSocketServer ----------------------------------------------------------------- Key: LBCLASSIC-127 URL: http://jira.qos.ch/browse/LBCLASSIC-127 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Reporter: Rick Janda Assignee: Logback dev list Hello Logback team, I use the RollingFileAppender in a SimpleSocketServer. The Messages are correctly written to the files but the files are not rolled at all. If I use the same appender config directly in my applications locally, it rolls the files as expected. The appender is configures as followed: <appender name="PAYLOAD_SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator class="com.swisscom.allip.logback.ContextBasedDiscriminator"> <DefaultValue>unknown</DefaultValue> </discriminator> <sift> <appender name="FILE-PAYLOAD-${contextName}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>${LOG_DIR}/payload-${contextName}.log</File> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <FileNamePattern>${LOG_DIR}/archive/payload-${contextName}_%d{yyyy-MM-dd}.log </FileNamePattern>  <MaxHistory>${MAX_HISTORY_DAYS}</MaxHistory> </rollingPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d{HH:mm:ss.SSS} refId: %mdc{refId} - %msg%n%xEx{full}</Pattern> </layout> </appender> </sift> </appender> Can you please have a look at this issue. Thank you in advance, Rick -- 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: (LBCLASSIC-126) NDC implementation
by Anders Wallgren (JIRA) 08 May '09

08 May '09

NDC implementation ------------------ Key: LBCLASSIC-126 URL: http://jira.qos.ch/browse/LBCLASSIC-126 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.15 Reporter: Anders Wallgren Assignee: Logback dev list Attachments: NDC.java The discussion about NDC vs. MDC has been done going for quite a while. I don't think MDC is a suitable replacement for NDC, except insofar as NDC can be implemented using MDC. Enclosed is the NDC implementation we're started using at Electric Cloud. Please feel free to adapt/modify/enhance it as you see fit. We place this code in the public domain in case others find it useful. Attachment to come as well. // NDC.java -- // // NDC.java is part of the ElectricCommander server. // // Copyright (c) 2005-2009 Electric Cloud, Inc. // All rights reserved. // package com.electriccloud.log; import java.util.Deque; import java.util.LinkedList; import org.jetbrains.annotations.NonNls; import org.jetbrains.annotations.NotNull; import org.slf4j.MDC; /** * Utility object that implements NDC using MDC. */ @SuppressWarnings({"UtilityClass", "StringContatenationInLoop"}) public class NDC { //~ Static fields/initializers --------------------------------------------- private static final ThreadLocal<Deque<String>> s_stack = new ThreadLocal<Deque<String>>() { @Override @SuppressWarnings({"RefusedBequest"}) protected Deque<String> initialValue() { return new LinkedList<String>(); } }; //~ Constructors ----------------------------------------------------------- private NDC() { } //~ Methods ---------------------------------------------------------------- public static void pop() { Deque<String> stack = s_stack.get(); // Pop the stack if isn't already empty if (!stack.isEmpty()) { stack.pop(); } // Put the previous value in the MDC (null if the stack is now empty) MDC.put("NDC", stack.peek()); } @SuppressWarnings({"HardCodedStringLiteral"}) public static void push(@NonNls @NotNull String format, Object... args) { Deque<String> stack = s_stack.get(); String previous = stack.peek(); String segment = args.length == 0 ? format : String.format(format, args); String newValue = previous == null ? segment : String.format("%s %s", previous, segment); stack.push(newValue); MDC.put("NDC", newValue); } } -- 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-124) wrong Output for %contextName in SimpleSocketServer with PatternLayout
by Rick Janda (JIRA) 20 Apr '09

20 Apr '09

wrong Output for %contextName in SimpleSocketServer with PatternLayout ----------------------------------------------------------------------- Key: LBCLASSIC-124 URL: http://jira.qos.ch/browse/LBCLASSIC-124 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Reporter: Rick Janda Assignee: Logback dev list Hello logback team, I found some unexpected behavior when trying to print out the log context name in the log message created by the SimpleSocketServer. %contextName in a PatternLayout of the SimpleSocketServer always creates "default" and not the context name submitted from the client. On the other side, context based discrimination works fine on the side of the SocketServer. Thus the context name seems to be correctly handed over to the SocketServer. Could you please have a look at this. Thank you in advance, Rick -- 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 Pavel (JIRA) 19 Apr '09

19 Apr '09

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Pavel commented on LBCORE-26: ----------------------------- I found the solution (or reason for wrong behavior) : in configuration file the setting for log file name <param name="File" value="filename.log" /> should appear BEFORE!!! the rollingPolicy entry <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logfile.%d{yyyy-MM-dd_HH-mm}.log.zip</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> > 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: Logback dev list > Priority: Critical > Fix For: 0.9.12 > > > 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

Using Thread to monitored TimeBasedRollingPolicy...!
by boss134 03 Apr '09

03 Apr '09

Dear sir, Yesterday night, i tried TimeBasedRollingPolicy class to logs the my code part. i used below configuration code in XML and after, used a single Thread to runs full night... When i see today morning, file created (myDebug.2009-04-02.zip) successfully. i extracted zip file after i verified yesterday log file. But, When see a current log file it keeps both logs (means yesterday and today logs). Actually this current log should contain today log only... i don't where am doing problem.... Please HELP me out... <appender name="FILEDEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>Debug/myDebug.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>myDebug.%d.zip</FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>DEBUG</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</Pattern> </layout> </appender> Thank you, boss134 -- View this message in context: http://www.nabble.com/Using-Thread-to-monitored-TimeBasedRollingPolicy...%2… Sent from the Logback Dev mailing list archive at Nabble.com.

2 4

More than one filter in Appender
by boss134 03 Apr '09

03 Apr '09

is it possible to support more than one filter in Appender...? -- View this message in context: http://www.nabble.com/More-than-one-filter-in-Appender-tp22862398p22862398.… Sent from the Logback Dev mailing list archive at Nabble.com.

2 2

[JIRA] Created: (LBCLASSIC-123) SocketNode constructor blocks due to ObjectInputStream creation
by Richard Fearn (JIRA) 02 Apr '09

02 Apr '09

SocketNode constructor blocks due to ObjectInputStream creation --------------------------------------------------------------- Key: LBCLASSIC-123 URL: http://jira.qos.ch/browse/LBCLASSIC-123 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.16 Environment: Using Logback 0.9.9, but problem is still present in trunk Reporter: Richard Fearn Assignee: Logback dev list Priority: Minor SocketNode implements Runnable, the implication being that a SocketNode can be run in its own thread like this: while (true) { // accept a client connection new Thread(new SocketNode(...)).start(); } However the SocketNode creates an ObjectInputStream using the socket's input stream, which blocks waiting for the stream header - so the constructor does not return, the thread cannot start and the loop shown above cannot continue until data has been received from the client. Typically a client would connect and immediately send data, so this wouldn't be an issue, but if someone just telnets to the log server and doesn't send any data, the above loop will block and prevent other clients' log messages from being processed. It would be better if the ObjectInputStream was created in the run() method to avoid the constructor blocking. -- 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-27) 0.9.15 OSGi import package specification in the 0.9.15 zip files specify dependencies on 0.9 instead of 0.9.15
by aappddeevv (JIRA) 31 Mar '09

31 Mar '09

0.9.15 OSGi import package specification in the 0.9.15 zip files specify dependencies on 0.9 instead of 0.9.15 -------------------------------------------------------------------------------------------------------------- Key: LBGENERAL-27 URL: http://jira.qos.ch/browse/LBGENERAL-27 Project: logback-general Issue Type: Bug Components: build-structure Affects Versions: 0.9.15 Environment: OSGi Reporter: aappddeevv Assignee: Logback dev list The logback classic MF specifies import package dependencies of 0.9 on logback core packages. But in the 0.9.15 zip, the logback core is level 0.9.15. This makes bundle resolution difficult under Equinox OSGi. In the same release, it appears that both logback core and logback are running at 0.9.15 and the import-package specification in logback classic MF should probably also specify the same release level since both core and classic are tagged at 0.9.15 instead of 0.9 in the same zip file anyway. -- 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 1

[JIRA] Created: (LBCLASSIC-122) %contextName with HTMLLayout produces empty logfiles
by Rick Janda (JIRA) 30 Mar '09

30 Mar '09

%contextName with HTMLLayout produces empty logfiles ---------------------------------------------------- Key: LBCLASSIC-122 URL: http://jira.qos.ch/browse/LBCLASSIC-122 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.15 Reporter: Rick Janda Assignee: Logback dev list Hello Logback team, I encountered a unexpected behavior when trying to print out the log context name in the html output. I configured a FileAppender with the following layout: <layout class="ch.qos.logback.classic.html.HTMLLayout"> <Pattern>%d{HH:mm:ss.SSS}%mdc{refId}%contextName%msg</Pattern> </layout> With this pattern, non of the log messages end up in the file. The output completely stops after the table header. If I remove "%contextName" from the pattern, I get my log messages written to the file as expected. Could you please have a look at this issue. Thank you in advance for your help. Kind regards, Rick -- 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: (LBGENERAL-26) Define taks for volunteers
by Ceki Gulcu (JIRA) 26 Mar '09

26 Mar '09

Define taks for volunteers -------------------------- Key: LBGENERAL-26 URL: http://jira.qos.ch/browse/LBGENERAL-26 Project: logback-general Issue Type: Improvement Reporter: Ceki Gulcu Assignee: Logback dev list Priority: Critical Fix For: 0.9.16 Create a web-page defining taks or areas of work for volunteers. -- 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