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

[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] (LOGBACK-727) ResilientFileOutputStream close method
by Dario Campagna (JIRA) 18 Dec '12

18 Dec '12

2 4

[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-235) Logback's TimeBasedRollingPolicy can't rename/move a file across filesystems
by Daniel Potter (JIRA) 11 Dec '12

11 Dec '12

Logback's TimeBasedRollingPolicy can't rename/move a file across filesystems ---------------------------------------------------------------------------- Key: LBCORE-235 URL: http://jira.qos.ch/browse/LBCORE-235 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.30 Environment: AIX 6.1, WebSphere 8.0.0.1 Reporter: Daniel Potter Assignee: Logback dev list Logback can't roll log files to a different filesystem than the active log using TimeBasedRollingPolicy (and RenameUtil.rename()) on AIX and possibly other Unix/Linux-based operating systems. Per the Java 6 File.renameTo() method JavaDoc, "The rename operation might not be able to move a file from one filesystem to another". The JavaDoc for RenameUtil.rename() states that it should fall back to renaming by copying, but the code doesn't do that. The renameByCopying() method is never called. -- 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 6

[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