May 2012 - logback-dev - mailman3.qos.ch

[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-301) MDC Adapter with configurable InheritableThreadLocal
by Alexander Treptow (JIRA) 01 Dec '12

01 Dec '12

MDC Adapter with configurable InheritableThreadLocal ---------------------------------------------------- Key: LBCLASSIC-301 URL: http://jira.qos.ch/browse/LBCLASSIC-301 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.9.28 Reporter: Alexander Treptow Assignee: Logback dev list Priority: Minor Attachments: LogbackMDCAdapter.java In our application we use a sifting file appender to log bot requests to a different log file than normal user requests. We have several sensor and aggregation threads that are started on different times that also have some logging output. My Problem: Log statements from request-independent threads are posted to bot.log and main.log on random. My Solution: I patched the LogbackMDCAdapter to be configureable by a system variable, to disable inheritance of the thread local member "copyOnInheritThreadLocal". The patched version defaults to old behavior, so it doesn't change if you do not configure it. To disable inheritance of that member, just pass "logback.threadlocal.inherit.copy=false" to the JVM. I applied the patch to Version 0.9.28 and tested it with our application. Maybe other logback users also want to configure logback in that way. -- 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 4

[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: (LBGENERAL-50) Swing Logger GUI (edit level and show root logger)
by Laurent Bourges (JIRA) 27 Nov '12

27 Nov '12

Swing Logger GUI (edit level and show root logger) -------------------------------------------------- Key: LBGENERAL-50 URL: http://jira.qos.ch/browse/LBGENERAL-50 Project: logback-general Issue Type: New Feature Environment: linux x86_64 / sun jdk 1.6+ Reporter: Laurent Bourges Assignee: Logback dev list Priority: Trivial I was using JUL and loggui (http://www.informatrix.ch/loggui/index.html) to edit logger's level at runtime and look at application logs in our Swing applications; it is very useful when applications are deployed using Java Web Start (jnlp environment) I switched to SLF4J 1.6.4 / LOGBACK 1.0 last week. As I wanted LogGui features for LogBack, I made it = LogbackGui (1 single and standalone java class): This class provides two major functionnalities: - application log viewer - one simple log GUI : Logger hierarchy browser / Level editor and displays current logs This class is dedicated to Slf4j @see http://www.slf4j.org/ (MIT License) using Logback @see http://logback.qos.ch/ (EPL v1.0 / LGPL 2.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

1 4

[JIRA] Created: (LBCORE-239) Minimal XSD schema for the Logback XML configuration file
by Geoffrey De Smet (JIRA) 14 Nov '12

14 Nov '12

Minimal XSD schema for the Logback XML configuration file --------------------------------------------------------- Key: LBCORE-239 URL: http://jira.qos.ch/browse/LBCORE-239 Project: logback-core Issue Type: New Feature Components: Other Affects Versions: 1.0.0 Reporter: Geoffrey De Smet Assignee: Logback dev list Although it's probably impossible to have an XSD schema that has every possible configuration element, it's possible to provide a valid XSD that allows any element at certain places, but does have a list of the common (= minimal set) of configuration elements, such as <configuration>, <appender> and <root>. How to have a specific element that can have any child element? {code}  <xs:element name="appender" minOccurs="0"> <xs:annotation> <xs:documentation source="version">1.0.0</xs:documentation> <xs:documentation source="description">TODO The appender ...</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:any minOccurs="0" maxOccurs="unbounded" processContents="skip"/> </xs:sequence> </xs:complexType> </xs:element> {code} Benefits: - Can be used to validate the xml in IntelliJ/Eclipse, without having to run it. - Code completion for XML in IntelliJ/Eclipse - The XSD description can explain what those "minimal" elements do. With IntelliJ (and Eclipse?) that "javadoc" pops up when writing it. - Can also be used by logback itself to validate the xml at runtime. -- 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 2

[JIRA] Created: (LBCLASSIC-279) Missing logging of Throwable in SyslogAppender
by Pasi Eronen (JIRA) 13 Nov '12

13 Nov '12

Missing logging of Throwable in SyslogAppender ---------------------------------------------- Key: LBCLASSIC-279 URL: http://jira.qos.ch/browse/LBCLASSIC-279 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.29 Reporter: Pasi Eronen Assignee: Logback dev list >From http://www.mail-archive.com/logback-dev@qos.ch/msg04990.html (Tobias Lund-Melcher, 05 October 2010): SyslogAppender does not seem to log the throwable type and its message at all. Tobias's message also included a patch. -- 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: (LBCLASSIC-325) Filtering out selected stack trace frames
by Tomasz Nurkiewicz (JIRA) 13 Nov '12

13 Nov '12

Filtering out selected stack trace frames ----------------------------------------- Key: LBCLASSIC-325 URL: http://jira.qos.ch/browse/LBCLASSIC-325 Project: logback-classic Issue Type: New Feature Components: appender, layout Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Priority: Minor Many frameworks and libraries like Spring or EJB are introducing hundreds of synthetic method invocations (AOP, dynamic proxies, CGLIB-generated classes, etc.) They are irrelevant for most of the time and only cluttering the stack traces printed by Logback. It would be nice to have possibility to filter (possibly by providing a set of patterns in logback.xml) each stack trace line and skip selected ones. Similar feature is implemented in some IDEs, see: http://blogs.jetbrains.com/idea/2010/07/console-folding-customization. -- 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

6 6

[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

[JIRA] Created: (LBCORE-209) Print configuration errors to stderr
by atomicknight (JIRA) 09 Nov '12

09 Nov '12

Print configuration errors to stderr ------------------------------------ Key: LBCORE-209 URL: http://jira.qos.ch/browse/LBCORE-209 Project: logback-core Issue Type: Improvement Components: Other Affects Versions: 0.9.28 Reporter: atomicknight Assignee: Logback dev list In org.slf4j.impl.StaticLoggerBinder#init(), any detected configuration errors are passed to StatusPrinter to be printed. However, the default PrintStream used by StatusPrinter is stdout, which can interfere with the output of command-line based Java programs that are used in the same fashion as applications such as ls or grep. Would it be possible to modify this behavior such that configuration errors are printed to stderr instead? A potential solution would be to overload StatusPrinter#printInCaseofErrorsOrWarning and StatusPrinter#printIfErrorsOccurred with versions that also take a PrintStream as an argument - this would allow classes like StaticLoggerBinder to specify the appropriate output stream without overriding the global state in StatusPrinter. Alternatively, an additional setting in the XML configuration might work just as well. -- 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 11