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

[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] 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

[JIRA] Created: (LBCORE-228) Syslog messages over 64K are discarded
by Pasi Eronen (JIRA) 25 Sep '12

25 Sep '12

Syslog messages over 64K are discarded -------------------------------------- Key: LBCORE-228 URL: http://jira.qos.ch/browse/LBCORE-228 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.30 Reporter: Pasi Eronen Assignee: Logback dev list SyslogAppenderBase truncates very long messages to 256k, which is not very useful limit, since SyslogOutputStream supports only UDP, which has maximum message size of 64k. Messages over 64k result in "java.io.IOException: Message too long" (from DatagramSocket.send, called from SyslogOutputStream.flush), but this exception is visible only in logger context status... Proposed fix: truncate long messages instead of discarding them. More specifically, change MSG_SIZE_LIMIT in SyslogAppenderBase to 65000. -- 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-319) SyslogAppender prints %PARSER_ERROR[nopexXXX] when suffixPattern doesn't start with [
by Markus Binsteiner (JIRA) 25 Sep '12

25 Sep '12

SyslogAppender prints %PARSER_ERROR[nopexXXX] when suffixPattern doesn't start with [ ------------------------------------------------------------------------------------- Key: LBCLASSIC-319 URL: http://jira.qos.ch/browse/LBCLASSIC-319 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.30, 1.0.0 Reporter: Markus Binsteiner Assignee: Logback dev list Priority: Minor When I use the SyslogAppender and specify a suffixPattern that starts with a whitespace or other character that is not [ logback seems to just append the string (until the first occurence of certain characters, e.g -) to the internal "%nopex" string. Subsequently it fails to parse the %nopexXXX string and prints something like: Jan 12 15:54:14 think %PARSER_ERROR[nopexXXX] [main] LogTest DEBUG FROM JAVA... to syslog. Had a look in the sourcecode, but couldn't figure out where it goes wrong, but I could confirm that if I add a whitespace to the string in this line String prefixPattern = "%syslogStart{" + facilityStr + "}%nopex "; there is no PARSER_ERROR. An additional whitespace in the logmessage though (I can live with that though). I need to be able to specify a string that doesn't start with [ though for some crazy reason (almost funny -- every other character would have been ok as far as I could figure out...). Any chance that could be looked into and included in one of the next releases? Thanks in advance... -- 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: (LBCORE-248) Logback Context is not thread safe, throws java.util.ConcurrentModificationException
by Svetla Arnaudova (JIRA) 22 Sep '12

22 Sep '12

Logback Context is not thread safe, throws java.util.ConcurrentModificationException ------------------------------------------------------------------------------------- Key: LBCORE-248 URL: http://jira.qos.ch/browse/LBCORE-248 Project: logback-core Issue Type: Bug Affects Versions: 1.0.0 Environment: Windows 7 OS, Java 1.6 build 1.6.0_27-b07, Tomcat 7 Reporter: Svetla Arnaudova Assignee: Logback dev list We see the following exception in Status messages for LoggerContext (see attached pic lbClassicStatus.jpg) java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at ch.qos.logback.classic.LoggerContext.syncRemoteView(LoggerContext.java:93) at ch.qos.logback.classic.LoggerContext.putProperty(LoggerContext.java:101) at ch.qos.logback.core.util.ContextUtil.addHostNameAsProperty(ContextUtil.java:42) at ch.qos.logback.classic.joran.action.ConfigurationAction.begin(ConfigurationAction.java:48) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:276) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:148) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:130) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:147) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:133) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:96) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:55) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at com.excilys.ebi.utils.spring.log.logback.LogbackConfigurer.initLogging(LogbackConfigurer.java:90) at com.excilys.ebi.utils.spring.log.logback.web.LogbackWebConfigurer.initLogging(LogbackWebConfigurer.java:92) at com.excilys.ebi.utils.spring.log.logback.web.LogbackConfigListener.contextInitialized(LogbackConfigListener.java:43) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723) at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226) at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Our web application set default configuration logback.xml file in the class path so that logback will use it to configure itself during initialization. It is slightly different (only set info level) from the default basic configuration, used in case there is no such file (see attached logback.xml). The real logback.xml configuration file is outside of the web application (attached as logback-conf.xml) and we reconfigure logapp to use it with spring integration lib https://github.com/excilys/spring-log Not sure that the rest of the description will be helpful to troubleshoot the problem, but this is how we reproduce it: This is the example code: <context-param> <param-name>logbackConfigLocation</param-name> <param-value>file:${basedir}/conf/logback.xml</param-value> </context-param> <listener> <listener-class>com.excilys.ebi.utils.spring.log.logback.web.LogbackConfigListener</listener-class> </listener> After spring is loaded LogbackConfigListener class will initialize logback from the given location and reset the logger context. Code snip from LogbackConfigListener init logging below: public static void initLogging(String location) throws FileNotFoundException, JoranException { String resolvedLocation = SystemPropertyUtils.resolvePlaceholders(location); URL url = ResourceUtils.getURL(resolvedLocation); ContextSelector selector = ContextSelectorStaticBinder.getSingleton().getContextSelector(); LoggerContext loggerContext = selector.getLoggerContext(); // in the current version logback automatically configures at startup // the context, so we have to reset it loggerContext.reset(); ContextInitializer contextInitializer = new ContextInitializer(loggerContext); contextInitializer.configureByResource(url); // reset JUL // don't forget to configure the LevelChangePropagator contextListener // in the config file!!! SLF4JBridgeHandler.install(); } We sometimes receive concurrency modification exception from the logback core code. We never observe this issue if we remove default logback file from the class path as initial configuration. To prevent this exception we also delay logback configuration loading. Thank you, Svetla -- 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] 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