January 2012 - 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: (LBGENERAL-48) Support JMX with Groovy Configuration
by Eric Pederson (JIRA) 10 Feb '13

10 Feb '13

Support JMX with Groovy Configuration ------------------------------------- Key: LBGENERAL-48 URL: http://jira.qos.ch/browse/LBGENERAL-48 Project: logback-general Issue Type: Improvement Reporter: Eric Pederson Assignee: Logback dev list Support JMX with Groovy Configuration. It is currently only supported in the XML config. -- 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-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: (LBCORE-216) Add a layout that produces JSON
by Pierre Queinnec (JIRA) 25 Jan '13

25 Jan '13

Add a layout that produces JSON ------------------------------- Key: LBCORE-216 URL: http://jira.qos.ch/browse/LBCORE-216 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.30 Reporter: Pierre Queinnec Assignee: Logback dev list Implement a layout producing JSON, possibly with no external dependencies. This enables having out-of-the-box experience connecting logback with external systems able to parse that format. I'll submit a patch as a pull request. For now this is commit : https://github.com/pmq/logback/commit/1161be30198ddca558363d92a282c7f975987… -- 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-306) Mixing periods and dollar signs in a logger name causes IllegalArgumentException from LoggerFactory.getLogger
by Michael Pilquist (JIRA) 23 Jan '13

23 Jan '13

Mixing periods and dollar signs in a logger name causes IllegalArgumentException from LoggerFactory.getLogger ------------------------------------------------------------------------------------------------------------- Key: LBCLASSIC-306 URL: http://jira.qos.ch/browse/LBCLASSIC-306 Project: logback-classic Issue Type: Bug Affects Versions: 1.0.0 Reporter: Michael Pilquist Assignee: Logback dev list When mixing periods and dollar signs in a logger name, an IllegalArgumentException is thrown from LoggerFactory.getLogger: scala> org.slf4j.LoggerFactory.getLogger("a.b$c.d") java.lang.IllegalArgumentException: For logger [a] child name [a.b$c passed as parameter, may not include '.' after index2 at ch.qos.logback.classic.Logger.createChildByName(Logger.java:386) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:152) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:48) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:253) Note that the following works: scala> org.slf4j.LoggerFactory.getLogger("a$b.c") res0: org.slf4j.Logger = Logger[a$b.c] -- 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-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-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