September 2011 - logback-dev

[JIRA] Created: (LBCLASSIC-157) Add option to include caller data in JMS Appender or to disable caller data in DB Appender
by Ging Ming Chan (JIRA) 22 Mar '12

22 Mar '12

Add option to include caller data in JMS Appender or to disable caller data in DB Appender ------------------------------------------------------------------------------------------ Key: LBCLASSIC-157 URL: http://jira.qos.ch/browse/LBCLASSIC-157 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.917 Reporter: Ging Ming Chan Assignee: Logback dev list Priority: Minor We are using the JMSQueueAppender remotely with a centralised server that uses the DBAppender to log to the database. However, since the JMSQueueAppender does not send the caller data, and the DBAppender always expect it, the operation never succeeded. There are two options to fix this, either add the includeCallerData option in the JMS Appender or to exclude caller data in the DB Appender. -- 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 4

[JIRA] Created: (LBCORE-213) Do not restrict SMTPAppender <to> to only 1 email address
by Alexandre Garnier (JIRA) 06 Mar '12

06 Mar '12

Do not restrict SMTPAppender <to> to only 1 email address --------------------------------------------------------- Key: LBCORE-213 URL: http://jira.qos.ch/browse/LBCORE-213 Project: logback-core Issue Type: Bug Reporter: Alexandre Garnier Assignee: Logback dev list It's not possible to have multiple email address in <to> element of SMTPAppender because only the first one is used (https://github.com/ceki/logback/blob/master/logback-core/src/main/java/ch/q…) When using a property, multiple <to> element is not really easy (if even possible)... Example: <appender name="email" class="ch.qos.logback.classic.net.SMTPAppender"> ... <to>${mail.log.to}</to> ... </appender> With properties : mail.log.to = admin@domain.com,dev@domain.com,op@domain.com => Only admin(a)domain.com get the email ! -- 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 5

[JIRA] Created: (LBCLASSIC-221) SMTPAppender includes irrelevant logging events
by Chris Cheshire (JIRA) 06 Mar '12

06 Mar '12

SMTPAppender includes irrelevant logging events ----------------------------------------------- Key: LBCLASSIC-221 URL: http://jira.qos.ch/browse/LBCLASSIC-221 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.24 Environment: Java6, Tomcat6 Reporter: Chris Cheshire Assignee: Logback dev list The BufferSize parameter to SMTPAppender has been removed with no replacement. When the SMTPAppender is triggered by an error event it also includes the previous 255 logging events, whether they were errors or not (now that the buffer size is fixed). By using BufferSize = 1, I was able to send a single error email every time an error occurred with just that error. Now I get completely irrelevant logging events, potentially days old with nothing to do with the error being logged and no simple way to change this. I'm not sure what version this was introduced - I just upgraded from 0.9.17 to 0.9.24. -- 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 5

[JIRA] Created: (LBCORE-210) Upgrade Janino support to latest 2.6.1
by Jason Klapste (JIRA) 21 Feb '12

21 Feb '12

Upgrade Janino support to latest 2.6.1 -------------------------------------- Key: LBCORE-210 URL: http://jira.qos.ch/browse/LBCORE-210 Project: logback-core Issue Type: Improvement Components: Joran Affects Versions: 0.9.28, 0.9.29 Reporter: Jason Klapste Assignee: Logback dev list Logback officially supports 2.4.3 (from 2006!) and should probably be upgraded to a more recent version. Janino 2.6.1 *WAS* working previously in logback (0.9.27) until EnvUtil.isJaninoAvailable()'s check was added. org.codehaus.janino.Cookable does not exist in 2.6.1. -- 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

7 10

[JIRA] Created: (LBCLASSIC-281) Don't evaluate formattedMessage in LoggingEvent constructor
by Andrew Brett (JIRA) 16 Feb '12

16 Feb '12

Don't evaluate formattedMessage in LoggingEvent constructor ----------------------------------------------------------- Key: LBCLASSIC-281 URL: http://jira.qos.ch/browse/LBCLASSIC-281 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.29 Reporter: Andrew Brett Assignee: Logback dev list Whenever a ch.qos.logback.classic.spi.LoggingEvent is constructed, MessageFormatter.arrayFormat(...) is called, and the formattedMessage member variable assigned. This involves calling toString() on all arguments in argArray, which can be slow, and occurs even if the formattedMessage is not part of any appender layouts. For my project's purposes, I have a custom formatter which only outputs an abbreviated string form of certain objects with expensive toString() methods; however, I am still paying the overhead in the toString() calls, since they're made even when getFormattedMessage() is never called. Note that I don't control the source of the objects with expensive toString() methods, nor do I control the source everywhere they're logged, so I can't simply change them directly. formattedMessage is already evaluated lazily in getFormattedMessage(), so the only side effect of this change is the introspection of argsArray to look for a Throwable at the end, which is a trivial operation to perform separately. -- 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-146) SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files
by Hrotkó Gábor (JIRA) 03 Feb '12

03 Feb '12

SiftingAppender TimeBasedRollingPolicy MaxHistory not deleting old files ------------------------------------------------------------------------ Key: LBCORE-146 URL: http://jira.qos.ch/browse/LBCORE-146 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.18 Environment: linux64, jdk1.6.0_17-b04, apache-tomcat-6.0.24 Reporter: Hrotkó Gábor Assignee: Logback dev list When I use SiftingAppender with TimeBasedRollingPolicy, old files does not get deleted when the MaxHistory is set. logback.xml snipet: <configuration debug="true" scan="true" scanPeriod="5 seconds"> <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender"> <discriminator> <Key>userid</Key> <DefaultValue>base</DefaultValue> </discriminator> <sift> <appender name="FILE-${userid}" class="ch.qos.logback.core.rolling.RollingFileAppender"> <File>/usr/local/tomcat6/logs/myLog_${userid}.log</File> <Append>false</Append> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%d [%thread] %level %mdc %logger.%method:%line - %msg%n</Pattern> </layout> <RollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>/usr/local/tomcat6/logs/myLog_${userid}.%d{yyyy-MM-dd}.log</FileNamePattern>  <MaxHistory>2</MaxHistory> </RollingPolicy> </appender> </sift> </appender> ... With the config above, the files gets sifted and rolled well, but old files not deleted. When I change the filenames, and delete the ${userid} sifting, it works well. ... <File>/usr/local/tomcat6/logs/myLog.log</File> ... <FileNamePattern>/usr/local/tomcat6/logs/myLog.%d{yyyy-MM-dd}.log</FileNamePattern> ... -- 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-284) Make it possible to log to different appenders at different levels from the same logger
by Iwein Fuld (JIRA) 10 Dec '11

10 Dec '11

Make it possible to log to different appenders at different levels from the same logger --------------------------------------------------------------------------------------- Key: LBCLASSIC-284 URL: http://jira.qos.ch/browse/LBCLASSIC-284 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.28 Reporter: Iwein Fuld Assignee: Logback dev list I found a requirement in the wild to log trace and above statements to one appender, and debug and above to another. This needed to be configured for a particular package. My preferred solution would be to use something like https://gist.github.com/1104145, but that doesn't work. There is a workaround of using a filter inside the appender, but that isn't as pretty as I would like. ( http://iweinfuld.posterous.com/ ) -- 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-261) MongoDB appender
by Tomasz Nurkiewicz (JIRA) 15 Nov '11

15 Nov '11

MongoDB appender ---------------- Key: LBCLASSIC-261 URL: http://jira.qos.ch/browse/LBCLASSIC-261 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.9.28 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list An appender similar to DbAppender, but storing logs in MongoDB document-oriented database. Should be capable of storing both classic and access logs. MongoDB seems especially well suited for this task since it is schema-less and very fast. Prototype implementation + integration tests (MongoDB instance running required) can be found here: https://github.com/nurkiewicz/logback/tree/mongodb-appender. -- 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-226) TimeBasedRollingPolicy does not trigger at application startup - MaxHistory not working
by Bruce E. Irving (JIRA) 08 Nov '11

08 Nov '11

TimeBasedRollingPolicy does not trigger at application startup - MaxHistory not working --------------------------------------------------------------------------------------- Key: LBCORE-226 URL: http://jira.qos.ch/browse/LBCORE-226 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.30 Environment: Windows XP, Java 1.6.0_27 Reporter: Bruce E. Irving Assignee: Logback dev list I am using the RollingFileAppender with TimeBasedRolliingPolicy. The application is a desktop utility that may be run several times per day but is almost never running at midnight when the roll would normally occur. The log file naming is working correctly - each day's file is date stamped, but the MaxHistory is not working at all since it is not enforced at app startup. Pertinent config section: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>MyApp_%d.log</fileNamePattern>  <maxHistory>7</maxHistory>  </rollingPolicy> <encoder> <pattern>%date %-5level [%thread] %logger{10} %msg%n</pattern> </encoder> </appender> I found what I believe is the source of the issue in TimeBasedFileNamingAndTriggeringPolicyBase: public void start() { ... setDateInCurrentPeriod(new Date(getCurrentTime())); if (tbrp.getParentsRawFileProperty() != null) { File currentFile = new File(tbrp.getParentsRawFileProperty()); if (currentFile.exists() && currentFile.canRead()) { setDateInCurrentPeriod(new Date(currentFile.lastModified())); } } addInfo("Setting initial period to " + dateInCurrentPeriod); computeNextCheck(); } Since there is no parentsRawFileProperty, this uses the current time and sets the next check at midnight tonight. Therefore the check is not run at startup, and in my case is never run. This would work fine if dateInCurrentPeriod was set to anything before today. I would suggest the following change: public void start() { ... File currentFile = new File(tbrp.getActiveFileName()); // Use same logic if ParentsRawFileProperty is set or not. if (currentFile.exists() && currentFile.canRead()) { setDateInCurrentPeriod(new Date(currentFile.lastModified())); } else { setDateInCurrentPeriod(0); // No current file found, force a triggering event // or if the above is too brute-force: setDateInCurrentPeriod(rc.getRelativeDate(new Date(), -1)); } addInfo("Setting initial period to " + dateInCurrentPeriod); computeNextCheck(); } Note - this was originally reported as a comment on LBCORE-147; moved here to be tracked as a separate issue. Thanks, -Bruce -- 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

Missing file from Git?
by Greg Thomas 29 Oct '11

29 Oct '11

I may have missed something, but I recently forked ceki/logback on github and it seems to be missing GafferConfigurator? It's referenced in the code, but not in the git source. Judging by the number of classes in that package (6 - http://logback.qos.ch/apidocs/ch/qos/logback/classic/gaffer/package-summary…) and the number of files in git (1 - https://github.com/ceki/logback/tree/master/logback-classic/src/main/java/c…) there could be as many as five files missing. I could always grab the source release, add them to my fork, and issue a pull request, but I suspect it's probably easier to simply add/commit the files that you probably already have. Greg

2 4