August 2010 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-162) Carriage return in PatternLayout in the XML configuration file
by Andres Gomez Casanova (JIRA) 07 Aug '10

07 Aug '10

Carriage return in PatternLayout in the XML configuration file -------------------------------------------------------------- Key: LBCORE-162 URL: http://jira.qos.ch/browse/LBCORE-162 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.18, 0.9.19, 0.9.24 Environment: Windows XP but probably all platforms Reporter: Andres Gomez Casanova Assignee: Logback dev list Priority: Minor Hi, I used to use the text formatting for the XML files in Eclipse, but sometimes the PatterLayout is too long, and the formatter divides it in two lines. --- BEFORE FORMAT --- <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern> %date{ISO8601} [%thread] %-5level %logger{35} - %message%n </pattern> </encoder> --- AFTER FORMAT --- <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern> %date{ISO8601} [%thread] %-5level %logger{35} - %message%n </pattern> </encoder> Then, the output in the ConsoleAppender will have two lines for each message logged. I think, the configuration reader has to ignore the carriage return in the file (in the middle of the patterLayout) and just only consider the %n. Thanks. Best regards Andrés Gómez Casanova -- 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

appender-ref attribute on <logger>
by Chad La Joie 03 Aug '10

03 Aug '10

Currently the appender reference for a logger needs to be added as a child element to the logger. I understand this is to allow multiple appenders to be attached to a single logger. However, my experience is that I rarely ever do that. I'd like to suggest adding an 'appender-ref' attribute to the logger to deal with this case. If you wanted to still be able to express multiple attached appenders with this mechanism you could use a space separated list. In the event that the appdender-ref attribute and element are both used you can simply attach the appenders listed in both. Thanks. -- Chad La Joie http://itumi.biz trusted identities, delivered

1 0

[JIRA] Created: (LBCORE-161) After a restart SizeAndTimeBasedFNATP uses incorrect sequence numbers for rollover files if compression is enabled
by Frank Bos (JIRA) 02 Aug '10

02 Aug '10

After a restart SizeAndTimeBasedFNATP uses incorrect sequence numbers for rollover files if compression is enabled ------------------------------------------------------------------------------------------------------------------ Key: LBCORE-161 URL: http://jira.qos.ch/browse/LBCORE-161 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Frank Bos Assignee: Logback dev list Priority: Minor To reproduce this issue you can use a setup similar to the one used for LBCORE-131, but then use a filename pattern like "log.%d{yyyy-MM-dd}.%i.txt.gz" for the RollingPolicy. This works fine as long as you don't restart the application that is doing the logging. The following files are created: {noformat} log.2010-08-02.0.txt.gz log.2010-08-02.1.txt.gz log.2010-08-02.2.txt ( = active log file) {noformat} However, after a restart the following happens: {noformat} log.2010-08-02.0.txt.gz log.2010-08-02.1.txt.gz log.2010-08-02.1.txt (!!) log.2010-08-02.2.txt.gz log.2010-08-02.3.txt.gz log.2010-08-02.4.txt (the active log file) {noformat} So there are now two versions of the logfile with index 1: one zipped and one unzipped. They do not contain the same messages! Also the order of the messages in these logfiles is not what I expected. After the restart logback will first create the 'log.2010-08-02.1.txt' file and after that it will fill the existing 'log.2010-08-02.2.txt' file to the rollover size. -- 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