April 2011 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-230) %cn conversion word fails in SMTPAppender subject
by Michael Osipov (JIRA) 24 Oct '12

24 Oct '12

%cn conversion word fails in SMTPAppender subject ------------------------------------------------- Key: LBCLASSIC-230 URL: http://jira.qos.ch/browse/LBCLASSIC-230 Project: logback-classic Issue Type: Bug Components: layout Affects Versions: 0.9.26 Reporter: Michael Osipov Assignee: Logback dev list According to the docs, the subject pattern equals to the pattern layout. Putting a %cn into it fails with an exception {noformat} <Subject>${HOSTNAME} %cn %level %X{ad.displayName} %logger{20} - %.20msg - %ex{-1}</Subject> {noformat} {noformat} 15:13:56,973 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.net.SMTPAppender] 15:13:57,045 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [EMAIL] 15:13:57,525 |-ERROR in ch.qos.logback.core.pattern.parser.Compiler@1a54421 - Failed to instantiate converter class [ch.qos.logback.classic.joran.action.ContextNameAction] ch.qos.logback.core.util.IncompatibleClassException at ch.qos.logback.core.util.IncompatibleClassException at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:47) at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(OptionHelper.java:31) at at ch.qos.logback.core.pattern.parser.Compiler.createConverter(Compiler.java:101) at at ch.qos.logback.core.pattern.parser.Compiler.compile(Compiler.java:58) at at ch.qos.logback.core.pattern.parser.Parser.compile(Parser.java:66) at at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:84) at at ch.qos.logback.classic.net.SMTPAppender.makeSubjectLayout(SMTPAppender.java:101) at at ch.qos.logback.core.net.SMTPAppenderBase.start(SMTPAppenderBase.java:155) at at ch.qos.logback.classic.net.SMTPAppender.start(SMTPAppender.java:60) at at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:96) at at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:315) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:194) at at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:180) at at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:52) at at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93) at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52) at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) at at com.siemens.ad.ld.listener.DataSourceService.<clinit>(DataSourceService.java:37) at at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at at java.lang.Class.newInstance0(Class.java:359) at at java.lang.Class.newInstance(Class.java:312) at at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4079) at at org.apache.catalina.core.StandardContext.start(StandardContext.java:4630) at at org.apache.catalina.core.StandardContext.reload(StandardContext.java:3391) at at org.apache.catalina.manager.ManagerServlet.reload(ManagerServlet.java:943) at at org.apache.catalina.manager.HTMLManagerServlet.reload(HTMLManagerServlet.java:556) at at org.apache.catalina.manager.HTMLManagerServlet.doGet(HTMLManagerServlet.java:121) at at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:563) at at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298) at at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:861) at at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:579) at at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1584) at at java.lang.Thread.run(Thread.java:619) 15:13:57,525 |-ERROR in ch.qos.logback.core.pattern.parser.Compiler@1a54421 - [cn] is not a valid conversion word 15:13:57,532 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] {noformat} %contextName does work. This is a bug -- 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-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-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: (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] 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