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

[JIRA] Created: (CONSPLUG-25) logback Console Plugin for Eclipse 3.6 has no any infomations outputed.
by jiaboming (JIRA) 28 Aug '12

28 Aug '12

logback Console Plugin for Eclipse 3.6 has no any infomations outputed. ------------------------------------------------------------------------- Key: CONSPLUG-25 URL: http://jira.qos.ch/browse/CONSPLUG-25 Project: Console Plugin Issue Type: Bug Environment: Eclipse 3.6 , WIN7 ch.qos.logback.eclipse_1.1.0, logback-0.9.24 Reporter: jiaboming Assignee: Logback dev list -- 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: (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: (CONSPLUG-26) Eclipse Helios Service Release 1 logback 0.9.26 does not work
by David Tkaczyk (JIRA) 28 Aug '12

28 Aug '12

Eclipse Helios Service Release 1 logback 0.9.26 does not work ------------------------------------------------------------- Key: CONSPLUG-26 URL: http://jira.qos.ch/browse/CONSPLUG-26 Project: Console Plugin Issue Type: Bug Components: other Environment: Linux 2.6.18-194.17.1.el5 x86_64 Reporter: David Tkaczyk Assignee: Logback dev list Plugin installs fine and "show views" creates a tab. <consolePlugin /> is added to logback.xml, but no logging ever occurs in this tab -- 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: (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: (LBCORE-252) Logback groovy configuration add support for Perf4j
by Muyen Lee (JIRA) 09 Aug '12

09 Aug '12

Logback groovy configuration add support for Perf4j ---------------------------------------------------- Key: LBCORE-252 URL: http://jira.qos.ch/browse/LBCORE-252 Project: logback-core Issue Type: Improvement Components: Appender Reporter: Muyen Lee Assignee: Logback dev list Priority: Minor I want to add an AsyncCoalescingStatisticsAppender. The XML confugration looks like this. <appender name="CoalescingStatistics" class="org.perf4j.logback.AsyncCoalescingStatisticsAppender"> <param name="TimeSlice" value="60000"/> <appender-ref ref="graphExecutionTimes"/> <appender-ref ref="graphExecutionTPS"/>  <appender-ref ref="perf4jJmxAppender"/> </appender> logback.groovy's appender function doesn't support <appender-ref ref="perf4jJmxAppender"/> The workaround is to write groovy directly JmxAttributeStatisticsAppender jmxAppender = new JmxAttributeStatisticsAppender() jmxAppender.name = "Per4j" jmxAppender.context = context jmxAppender.tagNamesToExpose="tag1, tag2" appenderList.add(jmxAppender) AsyncCoalescingStatisticsAppender coalAppender = new AsyncCoalescingStatisticsAppender() // in millisecond coalAppender.timeSlice=10000 coalAppender.name = "CoalescingStatistics" coalAppender.context = context coalAppender.addAppender(jmxAppender) appenderList.add(coalAppender) -- 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

[JIRA] Created: (LBCLASSIC-242) Implement AsyncAppender
by Andrew Kowal (JIRA) 25 Jul '12

25 Jul '12

Implement AsyncAppender ----------------------- Key: LBCLASSIC-242 URL: http://jira.qos.ch/browse/LBCLASSIC-242 Project: logback-classic Issue Type: New Feature Components: appender Reporter: Andrew Kowal Assignee: Logback dev list Logback still lacks AsynAppender like the one in Log4j. This feature is *critical* for production use in heavy loaded applications. This is the show stopper for us to migrate from Log4j to Logback. Some time ago there was similar issue LBCLASSIC-20, but it was closed after implementing async compression. So this one is just about asynchronous appender decorator. -- 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 4

[JIRA] (LBCLASSIC-332) SMTPAppender jndi JavaMail session supprt
by Hrotkó Gábor (JIRA) 17 Jul '12

17 Jul '12

2 4

[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: (LBCORE-242) log rollover should be configurable using %d multiple times in file name pattern
by Thomas Corte (JIRA) 09 Jul '12

09 Jul '12

log rollover should be configurable using %d multiple times in file name pattern -------------------------------------------------------------------------------- Key: LBCORE-242 URL: http://jira.qos.ch/browse/LBCORE-242 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 1.0.0 Reporter: Thomas Corte Assignee: Logback dev list Trying to configure a log rollover with logs being *rolled daily* and put into a directory named "yyyy-MM", i.e. one folder for each *month* containing that month's logs, I'm using the following appender config: {noformat} <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern%d{yyyy-MM}/app.%d{yyyy-MM-dd}.log</fileNamePattern> </rollingPolicy> <encoder> <pattern>%d{"yyyy-MM-dd HH:mm:ss,SSS"} [%thread] %-5level %logger{36} - %msg%n%xEx</pattern> </encoder> </appender> {noformat} However, it seems as if the current logback implementation merely considers the first %d specification, which leads to a log rotation only once per month instead of the desired once per day frequency. I figure this is because via %d, the log rotation frequency and the file name pattern are somewhat tied together and seemingly can't be specified independently. It would be nice if either multiple %d specifiers would be supported, with an option to specify which one should be considered for the rollover period. Even better, it might be a good idea to support the rollover period to be specified separately and independently from the file name pattern; arguably, using the file name patterns for both is somewhat convenient, but violates the principle of "separation of concerns". -- 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 10