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

Jenkins build is unstable: logback #2
by jenkins-no-reply＠cloudbees.com 04 Apr '13

04 Apr '13

See <https://logback.ci.cloudbees.com/job/logback/2/>

1 3

[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] (LOGBACK-717) If no config file is found, no debug info is printed out, even with logback.debug=true sys prop
by Antony Stubbs (JIRA) 18 Feb '13

18 Feb '13

4 21

[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] (LOGBACK-740) NPE in StaticLoggerBinder
by Matt Bishop (JIRA) 10 Jan '13

10 Jan '13

4 14

[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