September 2012 - logback-dev

[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] (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] (LOGBACK-753) Logback 1.0.7 fails to work in the presence of org.slf4j artifacts version > 1.7
by Matt Bishop (JIRA) 18 Dec '12

18 Dec '12

2 6

Splitting up logback-extensions project
by ceki 16 Dec '12

16 Dec '12

Hello all, Following up on a discussion on github [1], it seems reasonable to split the logback-extensions project into two separate umbrella projects with CLAs on file serving as the only separation criteria. The split does not have any relation to code quality or community health. The list of contributors with CLA on file can be found at [2]. Looking at the logback-extensions umbrella project, it appears that the following projects have been contributed by developers with CLAs on file eclipse/ (Tony Trinh) jackson/ (Les Hazlewood) json/ (Les Hazlewood, Pierre Quinnec) mongodb/ (Christian Trutz, Tomasz Nurkiewicz) as such, I propose that they remain in logback-extensions and be released under the ch.qos.logback.extensions groupID in Maven Central. If any contributor feels that the second umbrella project (see below) would be a better home, he/they is/are welcome to move to the second umbrella project and without prejudice. The following project contains contributions from developers without CLAs non file loggly/ (Les Hazlewood, Marten Gustafson) spring/ (Les Hazlewood, Bryan Turner, Juergen Hoeller) Marten Gustafson, Bryan Turner and Juergen Hoeller do not have CLAs on file. I propose that these projects be moved to a new umbrella project named logback-stuff/logback-etcetera/logback-sundries. We still have to determine the name. This project will be released under a groupId outside the "ch.qos" namespace. Given that this split bears no relation to code quality or community health, contributions should pick the umbrella project that pleases them most. Before going forward with the split, we must first pick a name for the second umbrella project. Here are the names I find suitable: logback-stuff, logback-etcetera and logback-sundries. Are there other suggestions for names? Cheers, [1] http://tinyurl.com/ckue3cu [2] http://tinyurl.com/signedCLAs -- Ceki http://tinyurl.com/proLogback

4 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