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

[JIRA] Created: (LBCLASSIC-279) Missing logging of Throwable in SyslogAppender
by Pasi Eronen (JIRA) 13 Nov '12

13 Nov '12

Missing logging of Throwable in SyslogAppender ---------------------------------------------- Key: LBCLASSIC-279 URL: http://jira.qos.ch/browse/LBCLASSIC-279 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.29 Reporter: Pasi Eronen Assignee: Logback dev list >From http://www.mail-archive.com/logback-dev@qos.ch/msg04990.html (Tobias Lund-Melcher, 05 October 2010): SyslogAppender does not seem to log the throwable type and its message at all. Tobias's message also included a patch. -- 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: (LBCLASSIC-325) Filtering out selected stack trace frames
by Tomasz Nurkiewicz (JIRA) 13 Nov '12

13 Nov '12

Filtering out selected stack trace frames ----------------------------------------- Key: LBCLASSIC-325 URL: http://jira.qos.ch/browse/LBCLASSIC-325 Project: logback-classic Issue Type: New Feature Components: appender, layout Reporter: Tomasz Nurkiewicz Assignee: Logback dev list Priority: Minor Many frameworks and libraries like Spring or EJB are introducing hundreds of synthetic method invocations (AOP, dynamic proxies, CGLIB-generated classes, etc.) They are irrelevant for most of the time and only cluttering the stack traces printed by Logback. It would be nice to have possibility to filter (possibly by providing a set of patterns in logback.xml) each stack trace line and skip selected ones. Similar feature is implemented in some IDEs, see: http://blogs.jetbrains.com/idea/2010/07/console-folding-customization. -- 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 6

[JIRA] Created: (LBCORE-171) Can't use logback on GAE SDK 1.3.7 when configured with logback.xml
by Maxim Veksler (JIRA) 10 Nov '12

10 Nov '12

Can't use logback on GAE SDK 1.3.7 when configured with logback.xml ------------------------------------------------------------------- Key: LBCORE-171 URL: http://jira.qos.ch/browse/LBCORE-171 Project: logback-core Issue Type: Bug Affects Versions: 0.9.24 Environment: GAE/J 1.3.7 Reporter: Maxim Veksler Assignee: Logback dev list Trying to initialize logback with custom configuration file (logback.xml) running on GAE platform throws the following exception Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: java.lang.NoClassDefFoundError: java.net.InetAddress is a restricted class. Please see the Google App Engine developer's guide for more details. at com.google.appengine.tools.development.agent.runtime.Runtime.reject(Runtime.java:51) at ch.qos.logback.core.util.ContextUtil.getLocalHostName(ContextUtil.java:30) at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:39) at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:47) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:273) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:127) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:40) at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:126) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) ...... This happens because ch.qos.logback.core.util.ContextUtil.java contains are reference to a java.net.InetAddress which is a restricted class on Google AppEngine Platform SDK 1.3.7: static String getLocalHostName() throws UnknownHostException { InetAddress localhost = InetAddress.getLocalHost(); return localhost.getHostName(); } I should note that BasicConfigurator is working and is able to configure the logback subsystem. A couple of resolutions I can think of: 1. Don't export this parameter by default, instead let the user choose if to define it or not in the logback.xml configuration file. 2. Create a "GAEConfigurator" which will use default for the limited GAE environment. 2. Provide a custom build for GAE platform, where this parameter will be taken from http://code.google.com/appengine/docs/java/javadoc/com/google/appengine/api… or not be defined at all. 4. Provide some method to override / use a different implementation of ContextUtil, one which will be suitable for GAE. -- 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] (LOGBACK-725) Logging System fails silently when config filename has an unsupported extension
by Ryan Scheidter (JIRA) 09 Nov '12

09 Nov '12

3 3

[JIRA] Created: (LBCORE-209) Print configuration errors to stderr
by atomicknight (JIRA) 09 Nov '12

09 Nov '12

Print configuration errors to stderr ------------------------------------ Key: LBCORE-209 URL: http://jira.qos.ch/browse/LBCORE-209 Project: logback-core Issue Type: Improvement Components: Other Affects Versions: 0.9.28 Reporter: atomicknight Assignee: Logback dev list In org.slf4j.impl.StaticLoggerBinder#init(), any detected configuration errors are passed to StatusPrinter to be printed. However, the default PrintStream used by StatusPrinter is stdout, which can interfere with the output of command-line based Java programs that are used in the same fashion as applications such as ls or grep. Would it be possible to modify this behavior such that configuration errors are printed to stderr instead? A potential solution would be to overload StatusPrinter#printInCaseofErrorsOrWarning and StatusPrinter#printIfErrorsOccurred with versions that also take a PrintStream as an argument - this would allow classes like StaticLoggerBinder to specify the appropriate output stream without overriding the global state in StatusPrinter. Alternatively, an additional setting in the XML configuration might work just as well. -- 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 11

[JIRA] (LOGBACK-728) XMLLayout does not escape &
by Gabriel Corona (JIRA) 30 Oct '12

30 Oct '12

2 4

[JIRA] Created: (LBCLASSIC-276) Add support for Throwable.getSuppressed()
by Joern Huxhorn (JIRA) 26 Oct '12

26 Oct '12

Add support for Throwable.getSuppressed() ----------------------------------------- Key: LBCLASSIC-276 URL: http://jira.qos.ch/browse/LBCLASSIC-276 Project: logback-classic Issue Type: New Feature Affects Versions: 0.9.29 Reporter: Joern Huxhorn Assignee: Logback dev list See http://old.nabble.com/Java-7-automatic-resource-management-and-suppressed-e… Java SE 7 adds a new feature to Throwable. http://www.oracle.com/technetwork/articles/java/trywithresources-401775.html explains this in detail. Relevant for us is the following new method: Throwable[] getSuppressed() It can optionally contain a list of Throwables that were suppressed by the new Java SE 7 try-with-resource functionality. We need to add support for that method be means of reflection. -- 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: (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: (LBCLASSIC-324) Allow specifying time zone in TimeBasedRollingPolicy's fileNamePattern
by William Ashley (JIRA) 21 Oct '12

21 Oct '12

Allow specifying time zone in TimeBasedRollingPolicy's fileNamePattern ---------------------------------------------------------------------- Key: LBCLASSIC-324 URL: http://jira.qos.ch/browse/LBCLASSIC-324 Project: logback-classic Issue Type: Improvement Components: appender Reporter: William Ashley Assignee: Logback dev list Priority: Minor I would like to have one of my application's logs use GMT for archive file names. The layout pattern currently supports specifying a time zone (documented under the conversion word 'd' http://logback.qos.ch/manual/layouts.html#conversionWord) but this is not supported when using the %d option with TimeBasedRollingPolicy (http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy) for file naming. -- 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: (LBCORE-247) SiftingAppender - Timeout for closing unused appenders should be configurable
by Tommy Becker (JIRA) 12 Oct '12

12 Oct '12

SiftingAppender - Timeout for closing unused appenders should be configurable ------------------------------------------------------------------------------ Key: LBCORE-247 URL: http://jira.qos.ch/browse/LBCORE-247 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 1.0.0 Reporter: Tommy Becker Assignee: Logback dev list Priority: Minor We are using SiftingAppender to direct logs for each job in our application to a separate file. These files are typically only written to a few times in pretty quick succession and then they're done. While the appender works well, we have found that we are creating jobs at a faster rate than it closes the sub-appenders, causing us to eventually run out of file descriptors. I know about AppenderTracker and will implement a solution using this, but this feels like this timeout value is something that should be configurable on the SiftingAppender. Or maybe just some kind of boolean to tell it to close sub-appenders more aggressively. -- 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 1