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

[JIRA] Created: (LBCORE-200) Add possibility to mark included file/resource optional
by Attila Király (JIRA) 20 Feb '13

20 Feb '13

Add possibility to mark included file/resource optional ------------------------------------------------------- Key: LBCORE-200 URL: http://jira.qos.ch/browse/LBCORE-200 Project: logback-core Issue Type: Improvement Components: Joran Affects Versions: 0.9.28 Reporter: Attila Király Assignee: Logback dev list Priority: Minor It would be nice if an <include /> element could be marked as optional. So if the file/resource is not found no error is logged about it (as it is now). -- 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-188) Log Rotation/Gzip process leaving .tmp files behind
by Bert B-L (JIRA) 18 Feb '13

18 Feb '13

Log Rotation/Gzip process leaving .tmp files behind --------------------------------------------------- Key: LBCORE-188 URL: http://jira.qos.ch/browse/LBCORE-188 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.26 Reporter: Bert B-L Assignee: Logback dev list We are seeing logback leave .tmp files behind in the log directory, presumably due to a hiccup during log rotation or gzip. Size 2365956 Dec 11 00:00 statsreceiver.log.2010-12-10.gz 2679618 Dec 12 00:01 statsreceiver.log.2010-12-11.gz 9190879942 Dec 12 04:00 statsreceiver-debug.log23124507802228260.tmp 2542799 Dec 13 00:00 statsreceiver.log.2010-12-12.gz 9137740366 Dec 13 04:00 statsreceiver-debug.log23210907242250260.tmp 543937393 Dec 13 20:07 statsreceiver-debug.log.2010-12-13_19:00.gz 548781049 Dec 13 22:07 statsreceiver-debug.log.2010-12-13_21:00.gz 2284216 Dec 14 00:00 statsreceiver.log.2010-12-13.gz 8127562 Dec 15 00:00 statsreceiver.log.2010-12-14.gz 19067117496 Dec 15 13:00 statsreceiver-debug.log23416102512001260.tmp 18177324477 Dec 15 16:00 statsreceiver-debug.log23426920509229260.tmp 2257423 Dec 15 23:00 statsreceiver-debug.log.2010-12-15_22:00.gz The logback jar versions are: WEB-INF/lib/logback-classic-0.9.26.jar WEB-INF/lib/logback-core-0.9.26.jar There is only a single application writing to those files, though it is conceivable that the .tmp droppings correlate to restarts of that application. If this is expected on application restarts, could logback start gzip'ing them again when it comes back? Here is the logback.xml file: <?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="60 seconds"> <appender name="FILE_WARN" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${logdir:-.}/${prog:-unknown}.log</file> <append>true</append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>warn</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${logdir:-.}/${prog:-unknown}.log.%d{yyyy-MM-dd}.gz</fileNamePattern> <maxHistory>7</maxHistory> </rollingPolicy> <encoder> <pattern>%-30(%d{yyyy-MM-dd HH:mm:ss} %.-1level :) %m Context:[%X{GTNDC_INFO}]%n</pattern> </encoder> </appender> <appender name="FILE_DEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${logdir:-.}/${prog:-unknown}-debug.log</file> <append>true</append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>debug</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${logdir:-.}/${prog:-unknown}-debug.log.%d{yyyy-MM-dd_HH:00}.gz</fileNamePattern> <maxHistory>36</maxHistory> </rollingPolicy> <encoder> <pattern>%-60(%d{yyyy-MM-dd HH:mm:ss} [%thread] %.-1level :) %m Context:[%X{GTNDC_INFO}]%n</pattern> </encoder> </appender> <logger name="org.apache.directory" level="WARN"/> <root><level value="debug"/> <appender-ref ref="FILE_WARN"/> <appender-ref ref="FILE_DEBUG"/> </root> </configuration> -- 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

9 21

[JIRA] Created: (LBCORE-123) File not rolling over with SizeBasedTriggeringPolicy & FixedWindowRollingPolicy
by Thomas Bednarek (JIRA) 08 Feb '13

08 Feb '13

File not rolling over with SizeBasedTriggeringPolicy & FixedWindowRollingPolicy ------------------------------------------------------------------------------- Key: LBCORE-123 URL: http://jira.qos.ch/browse/LBCORE-123 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.17 Environment: Solaris 10 10/08 s10s_u6wos_07b SPARC Copyright 2008 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 27 October 2008 Reporter: Thomas Bednarek Assignee: Logback dev list I have a process that is kicked off by cron. It is suppose to role the file over with a size 1M. It doesn't. When I set it to 10K, it still doesn't. Here is my config file: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender class="ch.qos.logback.core.rolling.RollingFileAppender" name="RootFileAppender"> <file>XMLExtract.log</file> <append>true</append> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>info</level> </filter> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>/u01/oracle/XmlExtract/XMLExtract.%i.zip</fileNamePattern> <maxIndex>5</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>1M</maxFileSize> </triggeringPolicy> <layout class="ch.qos.logback.classic.PatternLayout"> <pattern>%d{<yyyy-MM-dd [HH:mm:ss.SSS]>},[%C{1}],[%M] --- %m%n</pattern> </layout> </appender> <root> <level value="info"/> <appender-ref ref="RootFileAppender"/> </root> </configuration> I looked at http://jira.qos.ch/browse/LBCLASSIC-105 and as you can see, I put the full path of where I want the files to be archived. However, that has not worked for me either. -- 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 4

[JIRA] Created: (LBCLASSIC-249) Logging Exceptions using DBAppender fails (at least on Oracle), when message or stack frame is longer than 254 bytes
by Andreas Zielke (JIRA) 07 Jan '13

07 Jan '13

Logging Exceptions using DBAppender fails (at least on Oracle), when message or stack frame is longer than 254 bytes -------------------------------------------------------------------------------------------------------------------- Key: LBCLASSIC-249 URL: http://jira.qos.ch/browse/LBCLASSIC-249 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.28 Environment: Oracle DBMS Reporter: Andreas Zielke Assignee: Logback dev list Priority: Minor Sometimes the DBAppender failed to log Exceptions, so I checked the status of the StatusManager and found the folloging problem: java.sql.BatchUpdateException: ORA-12899: Wert zu groß für Spalte "SUBSYSTEMTEST"."LOGGING_EVENT_EXCEPTION"."TRACE_LINE" (aktuell: 692, maximal: 254) Possible fix: After reading the code of DBAppender I subclassed it and changed the code of the method void updateExceptionStatement(PreparedStatement exceptionStatement, String txt, short i, long eventId) so that the text would be shortened accordingly. This seems to be the most consistent workaround, as many other columns are also only 254 bytes wide. I'd much rather have a wider column and not loose information, though. (This would be consistent with the changes to LOGGING_EVENT_EXCEPTION as proposed in LBCLASSIC-170). -- 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-52) Make SyslogAppenderBase fields protected
by Anton Tagunov (JIRA) 27 Dec '12

27 Dec '12

Make SyslogAppenderBase fields protected ---------------------------------------- Key: LBCORE-52 URL: http://jira.qos.ch/browse/LBCORE-52 Project: logback-core Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Hi! We'd like to customize some of SyslogAppender. Since SyslogAppenderBase class is public and is a base class by destination would it be appropriate to have all of the fields be designated as 'protected'? -- 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 5

[JIRA] Created: (LBCLASSIC-202) ServletContextListener to relocate logback config, implementation provided
by Attila Király (JIRA) 18 Dec '12

18 Dec '12

ServletContextListener to relocate logback config, implementation provided -------------------------------------------------------------------------- Key: LBCLASSIC-202 URL: http://jira.qos.ch/browse/LBCLASSIC-202 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.20 Reporter: Attila Király Assignee: Logback dev list In spring there is a Log4jConfigListener which can be used to reconfigure the default location of the log4j config. I always liked to use it because so I could relocate my log4j.xml from the classes directory next to the web.xml so the config files were at one place. Because I did not find something like that I wrote one for logback. I think it could be included into logback-classic. ch.qos.logback.classic.servlet.LogbackConfigListener configuration is very easy: 1. Add the listener to the web.xml (it should be the first listener so logback gets configured before the other listeners start up): <listener> <listener-class>ch.qos.logback.classic.servlet.LogbackConfigListener</listener-class> </listener> 2. Add a context-param to web.xml to specify the location of the logback config: <context-param> <param-name>logbackConfigLocation</param-name> <param-value>/WEB-INF/log.xml</param-value> </context-param> And thats it. The location is resolved in the following way (similar to spring aproach): - if the location starts with "/" it is resolved as servlet context resource - otherwise an URL is constructed from it. So you can use locations like this also: file:/foo/bar/logback.xml or file:d:/foo/bar/logback.xml - if the the first method fails a java.io.FileInputStream is created from the location to be used as input for logback configuration. - If none of the above worked an error is logged to servlet log but no exception is thrown. The location can contain system properties, those gets resolved. So a location can be configured for example to: file:${user.home}/configuration/log.xml The original spring listener only worked with expanded wars this logback variant does not have this requirement. -- 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

9 14

[JIRA] Created: (LBCORE-184) FileAppender should permit lazy file creation
by Eric Estievenart (JIRA) 05 Dec '12

05 Dec '12

FileAppender should permit lazy file creation --------------------------------------------- Key: LBCORE-184 URL: http://jira.qos.ch/browse/LBCORE-184 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: 0.9.26 Reporter: Eric Estievenart Assignee: Logback dev list There should be an option to allow lazy file creation, so that the files are created only when an event has to be logged into it, and not when the appender starts. The main idea behind that is that I dislike seeing files like ERROR.log (or even worse CRASH.log !) in the log folders, even if their size is zero. And these files are probably even rolled over (at least with time based policy), which can generate many (empty and useless) files with frightening names. I think that something like <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <lazy>true</lazy> ... </appender> would be very convenient, as well as a way to globally set all file based appenders lazy (or not) at once: <configuration> <lazyFileAppenders/> </configuration> (or whatever people may find more convenient, maybe <FileAppenders lazy="true"/> ) (because you may not want to add that on a dozen or more file appenders). This applies to all file appenders, including rolling ones, and maybe others ? BTW, the more I use logback the more impressed I am. You deserve a gold medal for your good job guys ! (and I don't give so many) -- 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: (LBCLASSIC-260) Recording appender that dumps debug messages only when error occurs
by Tomasz Nurkiewicz (JIRA) 04 Dec '12

04 Dec '12

Recording appender that dumps debug messages only when error occurs ------------------------------------------------------------------- Key: LBCLASSIC-260 URL: http://jira.qos.ch/browse/LBCLASSIC-260 Project: logback-classic Issue Type: New Feature Components: appender Affects Versions: 0.9.28 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Provide built-in utility appender that silently stores last few logging messages and dumps them (forwards to a target appender) only when an error occurs. Older logging events are replaced with new ones. This is a configuration example: <configuration> <appender name="REC" class="ch.qos.logback.classic.RecordingAppender"> <appender-ref ref="STDOUT"/> <maxEvents>1000</maxEvents> <dumpThreshold>WARN</dumpThreshold> <expiryTimeMs>15000</expiryTimeMs> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%-4relative [%thread] %-5level - %msg%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="REC"/> </root> </configuration> Such an appender is crafted manually by several users, it would be nice to provide it out of the box. I already implemented this feature (100% test coverage): https://github.com/nurkiewicz/logback/tree/recording-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

3 3

[JIRA] Created: (LBCLASSIC-225) Please add system property to enable debugging of config loading
by Aaron Digulla (JIRA) 28 Nov '12

28 Nov '12

Please add system property to enable debugging of config loading ---------------------------------------------------------------- Key: LBCLASSIC-225 URL: http://jira.qos.ch/browse/LBCLASSIC-225 Project: logback-classic Issue Type: New Feature Components: joran Affects Versions: 0.9.26 Reporter: Aaron Digulla Assignee: Logback dev list This has bugged me several times already: There is no way to set ConfigurationAction.debugMode from a system property. Use cases: - Enable debugging for a quick check without modifying sources (= no accidental commit) - Enable debugging to figure out which logback config is loaded in production (for example if one crept into a JAR file). -- 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 11

[JIRA] Created: (LBCORE-171) Can't use logback on GAE SDK 1.3.7 when configured with logback.xml
by Maxim Veksler (JIRA) 10 Nov '12

10 Nov '12

Can't use logback on GAE SDK 1.3.7 when configured with logback.xml ------------------------------------------------------------------- Key: LBCORE-171 URL: http://jira.qos.ch/browse/LBCORE-171 Project: logback-core Issue Type: Bug Affects Versions: 0.9.24 Environment: GAE/J 1.3.7 Reporter: Maxim Veksler Assignee: Logback dev list Trying to initialize logback with custom configuration file (logback.xml) running on GAE platform throws the following exception Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.NoClassDefFoundError: java.net.InetAddress is a restricted class. Please see the Google App Engine developer's guide for more details. at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:51) at ch.qos.logback.core.util.ContextUtil.getLocalHostName(ContextUtil.java:30) at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:39) at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:47) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:273) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:127) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:40) at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) ...... This happens because ch.qos.logback.core.util.ContextUtil.java contains are reference to a java.net.InetAddress which is a restricted class on Google AppEngine Platform SDK 1.3.7: static String getLocalHostName() throws UnknownHostException { InetAddress localhost = InetAddress.getLocalHost(); return localhost.getHostName(); } I should note that BasicConfigurator is working and is able to configure the logback subsystem. A couple of resolutions I can think of: 1. Don't export this parameter by default, instead let the user choose if to define it or not in the logback.xml configuration file. 2. Create a "GAEConfigurator" which will use default for the limited GAE environment. 2. Provide a custom build for GAE platform, where this parameter will be taken from http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api… or not be defined at all. 4. Provide some method to override / use a different implementation of ContextUtil, one which will be suitable for GAE. -- 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