July 2010 - logback-dev - mailman3.qos.ch

[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-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: (CONSPLUG-17) All messages appear as null
by Antony Stubbs (JIRA) 28 Aug '12

28 Aug '12

All messages appear as null --------------------------- Key: CONSPLUG-17 URL: http://jira.qos.ch/browse/CONSPLUG-17 Project: Console Plugin Issue Type: Bug Environment: Version: 3.4.1 Build id: M20080911-1700 Logback-Plugin Version: 1.1.0 Slf4j: 1.5.6 Logback-core/Logback-classic: 0.9.14 Reporter: Antony Stubbs Assignee: Logback dev list Priority: Blocker I *suspect* - not, this is only a *hunch* mind you.... That this has something to do with this message on the site - "Unfortunately, the console plugin is somewhat outdated. It expects logback version 0.9.9. It will be upgraded in the coming weeks." ;) Hopefully this can get covered up soon as I'm in a bit of a bind - some bug in 0.9.9 is ignoring my root logger level of INFO so i'm being flooded with DEBUG messages. And 1.5.6 doesn't show anything :/ I suspect that message on the site is pretty old too.... I spotted a msg on the maililng list somewhere about this, but I lost it. -- 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: (CONSPLUG-19) Stack trace icon is sometimes not displayed
by Richard Fearn (JIRA) 28 Aug '12

28 Aug '12

Stack trace icon is sometimes not displayed ------------------------------------------- Key: CONSPLUG-19 URL: http://jira.qos.ch/browse/CONSPLUG-19 Project: Console Plugin Issue Type: Bug Components: interface Environment: Red Hat Enterprise Linux 5, Eclipse 3.5 Reporter: Richard Fearn Assignee: Logback dev list Priority: Minor The stack trace icon at the left hand side of the Logback View isn't always displayed. If a logging event with a stack trace is displayed in the view first, the icon is displayed in the first row and the view seems to work normally. But if an event without a stack trace is displayed first, without an icon, the icon doesn't seem to be displayed for all subsequent rows. I think this might due to using a virtual table with a label provider that provides {{null}} column images. I've changed {{getColumnImage}} to return a blank image instead of {{null}} if the event doesn't have a stack trace, and that seems to fix the problem. -- 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 4

[JIRA] Created: (CONSPLUG-20) Move LogbackPlugin code to git
by Rüdiger (JIRA) 28 Aug '12

28 Aug '12

Move LogbackPlugin code to git ------------------------------ Key: CONSPLUG-20 URL: http://jira.qos.ch/browse/CONSPLUG-20 Project: Console Plugin Issue Type: Task Reporter: Rüdiger Assignee: Logback dev list The code for the LogbackPlugin is not in the general GIT repository. It seems to live in subversion only. The comment "Unfortunately, the console plugin is somewhat outdated. It expects logback version 0.9.9. It will be upgraded in the coming weeks." shows some age by now... maybe someone wants to help out. -- 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: (CONSPLUG-16) Make the Consol plugin available via an update site
by Szel Zoltan (JIRA) 28 Aug '12

28 Aug '12

Make the Consol plugin available via an update site --------------------------------------------------- Key: CONSPLUG-16 URL: http://jira.qos.ch/browse/CONSPLUG-16 Project: Console Plugin Issue Type: Task Components: other Reporter: Szel Zoltan Assignee: Logback dev list Hi, making the Consol plugin available via an Update Site would make the install of the plugin much easier for developers. Please consider creating one for this very useful plugin. Thanks in advance! Best Regardsm Zoltan Szel -- 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 6

[JIRA] Created: (LBCLASSIC-212) Logback classic doesn't work with Tomcat
by Grzegorz Borkowski (JIRA) 21 Aug '12

21 Aug '12

Logback classic doesn't work with Tomcat ---------------------------------------- Key: LBCLASSIC-212 URL: http://jira.qos.ch/browse/LBCLASSIC-212 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.21 Reporter: Grzegorz Borkowski Assignee: Logback dev list Priority: Critical We have a web application running on Tomcat 6.0.26, which uses SLF4J for logging. Until now, we used SLF4J-Simple, and it worked very well. Now we try to switch to Logback, but we are not able to make it work. It works for logging one-line messages. But whenever any exception is thrown on server, which should print a stack trace, server hangs (It doesn't matter whether we actually print the stack trace in log or not). From what I was able to observe, it looks like it falls into endless loop, throwing "ClassNotFoundException: ch.qos.logback.classic.spi.ThrowableProxyUtil", which is caught and tried to be logged, which throws this exception again, and so on. I don't know why it throws this ClassNotFoundException - perhaps classloader issue? But even copying the logback jars to Tomcat's lib directory, I'm not able to run the application: than it has problems with starting up. Sometimes it freezes during loading web app, and often it helps to attach and detach debugger to Tomcat - it's a kind of magic... Anyway, it's horrendously painful, and I'm not able to make it work. Why such common setup (webapp on Tomcat) is not described in Logback documentation??? This is our configuration file : <configuration scan="true"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n%ex</pattern> </encoder> </appender> <root level="info"> <appender-ref ref="STDOUT" /> </root> </configuration> (changing scan to "false" doesn't help. Also changing pattern to the one not containing "%ex" doesn't help) This is part of pom file related to logging: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>0.9.21</version> <scope>runtime</scope> </dependency>  <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.1</version> <scope>provided</scope> </dependency>  <dependency> <groupId>org.slf4j</groupId> <artifactId>jcl-over-slf4j</artifactId> <version>1.6.0</version> </dependency> If we change dependency from logback to SLF4J simple (1.6.0) than everything works smoothly, stacktraces are printed to console, no freezing, everything is perfect. -- 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 21

[JIRA] Created: (LBCLASSIC-52) Allow multiple addresses for "to" property of SMTPAppender
by JIRA Administrator (JIRA) 11 Jul '12

11 Jul '12

Allow multiple addresses for "to" property of SMTPAppender ---------------------------------------------------------- Key: LBCLASSIC-52 URL: http://jira.qos.ch/browse/LBCLASSIC-52 Project: logback-classic Issue Type: Improvement Reporter: Andrey Utkin Assignee: Ceki Gulcu SMTPAppender don`t allow to specify multiple addresses in single "to" property. So that, it is (almost?) impossible to specify multiple "to" addresses via variable substitution. We should know exact number of addresses (variables) to specify appropriate quantity of <to> elements. But number of "to" addresses could be changed during application using and differ from customer to customer. So, IMFO it will be helpful to allow specifying multiple addresses in one <to> element. Multiple addresses could be separated by comma, for example (as comma is not valid character for email address). Right now we are using simple workaround. We subclass SMTPAppender and overwrite addTo(): {code} @Override public void addTo(String to) { StringTokenizer st = new StringTokenizer(to, ","); while(st.hasMoreTokens()) { super.addTo(st.nextToken().trim()); } } {code} This solution works just fine for us. May be it will be good to include this feature in core logback too. -- 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 6

[JIRA] Created: (LBCLASSIC-74) NullPointerException in Logger after container restart
by Manel Clos (JIRA) 11 Jun '12

11 Jun '12

NullPointerException in Logger after container restart ------------------------------------------------------ Key: LBCLASSIC-74 URL: http://jira.qos.ch/browse/LBCLASSIC-74 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.9 Environment: Eclipse 3.4, Java 5, Tomcat 5.5.26, plain JSP (no servlet) Reporter: Manel Clos Assignee: Logback dev list Hi, loggerContext in the Logger class is null after container restart. This will produce a NPE when trying to further use logback. java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:775) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:630) at ch.qos.logback.classic.Logger.isDebugEnabled(Logger.java:613) at test.LogbackTest.testLogger(LogbackTest.java:15) -- 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 8