October 2011 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-169) RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory
by Tomasz Nurkiewicz (JIRA) 24 Apr '12

24 Apr '12

RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory -------------------------------------------------------------------------------------- Key: LBCORE-169 URL: http://jira.qos.ch/browse/LBCORE-169 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list When using ZIP feature to compress old log files, Logback does not allow to put ZIP files in different directory like in this example: <file>logs\server.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs\arch\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> </rollingPolicy> Running the attached test maven project (it takes 1 minute to run) will create server.log3560979839057.tmp (or similar) temporary file instead of ZIP file in /arch subdirectory (preferably this directory should be created if not exists). If fileNamePattern in rollingPolicy is changed to: "logs\server.%d{yyyy-MM-dd_HHmm}.log.zip" everything works as expected. The root of this issue is to be able to automatically ZIP files AND archive them in different directory. It would be great to be able to use date placeholders in folder names, for instance: <fileNamePattern>logs\arch-%d{yyyy-MM}\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> so that Logback would automatically create folders for each month with ZIPped files. -- 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

8 9

[JIRA] Created: (LBCORE-84) Typo in PropertyAction
by Michael Franz (JIRA) 24 Apr '12

24 Apr '12

Typo in PropertyAction ---------------------- Key: LBCORE-84 URL: http://jira.qos.ch/browse/LBCORE-84 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.14 Reporter: Michael Franz Assignee: Logback dev list Priority: Trivial The following message is printed |-WARN in ch.qos.logback.core.joran.action.PropertyAction - [substitutionProperty] element has been deprecated. Plase use the [property] element instead. There an 'e' missing in "Please". -- 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-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-298) improve RollingCalendar and TimeBasedFileNamingAndTriggeringPolicyBase to enable periodic loggic
by Murali Rath (JIRA) 20 Dec '11

20 Dec '11

improve RollingCalendar and TimeBasedFileNamingAndTriggeringPolicyBase to enable periodic loggic ------------------------------------------------------------------------------------------------ Key: LBCLASSIC-298 URL: http://jira.qos.ch/browse/LBCLASSIC-298 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.9.29 Environment: all Reporter: Murali Rath Assignee: Logback dev list logback currently allows logging periodically however it is limited to every 1 sec, 1 min, 1 hr , 1 day etc. When I want the log file to roll over say every 10 sec or 20 minutes it is not possible. RollingCalendar and TimeBasedFileNamingAndTriggeringPolicyBase can be improved or extened to provide this functionality. -- 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 3

[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