November 2010 - logback-dev

[JIRA] Created: (LBCLASSIC-156) SocketAppender is reporting an WARN if connection could not be established.
by Joern Huxhorn (JIRA) 28 Mar '11

28 Mar '11

SocketAppender is reporting an WARN if connection could not be established. --------------------------------------------------------------------------- Key: LBCLASSIC-156 URL: http://jira.qos.ch/browse/LBCLASSIC-156 Project: logback-classic Issue Type: Improvement Components: appender Affects Versions: 0.917 Environment: java version "1.6.0_15" Java(TM) SE Runtime Environment (build 1.6.0_15-b03-226) Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-92, mixed mode) Reporter: Joern Huxhorn Assignee: Logback dev list This is a followup to LBCLASSIC-143 which changed the message from ERROR to WARN. The WARN message still results in a dump of the logging status messages. This means that a whole bunch of text is printed to the console whenever Lilith is started - and it looks quite broken due to the stacktrace. So there are two possible solutions for this problem: a) the status is only printed in case of an ERROR b) SocketAppender considers this as an INFO instead of a WARN. I think b) would be reasonable. Other WARNs are much more important, like duplicate logback.xml. Lilith is only an example, btw. We routinely add SocketAppender[localhost] to our console applications. In case of trouble one can simply start Lilith and check the logs that way instead of reading them on the console. The default use-case is executing the app without Lilith, though, so we get the logback status messages on every start - which is quite noisy and annoying. -- 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 5

[JIRA] Created: (LBCORE-166) RenameUtil not truncating file if delete fails during rollover
by Jose David Barrio (JIRA) 18 Mar '11

18 Mar '11

RenameUtil not truncating file if delete fails during rollover -------------------------------------------------------------- Key: LBCORE-166 URL: http://jira.qos.ch/browse/LBCORE-166 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Environment: Microsoft Windows XP SP2 OAS 10.1.3.4 Java 1.5.0_14 Reporter: Jose David Barrio Assignee: Logback dev list Priority: Minor Attachments: RenameUtil.patch When using logback under Windows over Oracle Application Server, if you redeploy the web application, the log file is keep open by some reason so when a new rollover happens it fails to rename the log file. Currently RenameUtil does: - Try to rename log file. - If rename fails then rename by copy (copy plus delete). If for some reason deletion fails the log file keeps all its content so I just added a truncate if deletion fails: - Try to rename log file. - If rename fails then rename by copy (copy plus delete). - If delete fails then truncate file. I do have a patch file if it's useful. -- 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 7

[JIRA] Created: (LBGENERAL-37) Need to scan included files
by lala (JIRA) 10 Feb '11

10 Feb '11

Need to scan included files --------------------------- Key: LBGENERAL-37 URL: http://jira.qos.ch/browse/LBGENERAL-37 Project: logback-general Issue Type: New Feature Reporter: lala Assignee: Logback dev list Priority: Minor I'm using the following configuration and I'm looking for a method to scan included files. <configuration scan="true" scanPeriod="10 seconds"> <insertFromJNDI env-entry-name="java:comp/env/logback-file" as="logback-file" /> <contextName>lala</contextName> <include file="${logback-file}" /> </configuration> Once scan directive is used, logback is going to rescan this file every 10 seconds whether its modification date has changed. The issue is that I have to overwrite the previous file in order to rescan the target ${logback-file}. I suggest adding an attribute in the configuration marker in order to force logback to scan included files . It could be something like that: <configuration scan="true" scanPeriod="10 seconds" scanIncluded="true"> ..... </configuration> In order to process this task, at each scan logback should memorize the reference to the included files, and their latest modification date. Consequently, every 10 seconds, logback check the whole list of files and rescan the main file if something has changed. -- 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 5

[JIRA] Created: (LBCLASSIC-227) HOSTNAME property not resolved
by Simon Kelly (JIRA) 10 Feb '11

10 Feb '11

HOSTNAME property not resolved ------------------------------ Key: LBCLASSIC-227 URL: http://jira.qos.ch/browse/LBCLASSIC-227 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.26 Reporter: Simon Kelly Assignee: Logback dev list When using the hostname property the following ERROR message is logged: Appender [EMAIL] of type [ch.qos.logback.classic.net.SMTPAppender] has no appplicable [HOSTNAME] property Configuration as below: ======================================================= import ch.qos.logback.classic.encoder.PatternLayoutEncoder import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.classic.net.SMTPAppender import ch.qos.logback.core.status.OnConsoleStatusListener import ch.qos.logback.classic.PatternLayout import ch.qos.logback.classic.html.HTMLLayout import static ch.qos.logback.classic.Level.TRACE import static ch.qos.logback.classic.Level.DEBUG import static ch.qos.logback.classic.Level.INFO import static ch.qos.logback.classic.Level.WARN import static ch.qos.logback.classic.Level.ERROR statusListener(OnConsoleStatusListener) def appenderList = ["Console"] def enable_email = true if(enable_email) { appender("EMAIL", SMTPAppender) { SMTPHost = "smtp.gmail.com" SMTPPort = 587 STARTTLS = true username = "username" password = "password" to = "to(a)demo.com" from = "from(a)demo.com" subject = "ERROR from ${HOSTNAME}: %logger{20} - %m" layout(HTMLLayout) { pattern = "%d{HH:mm:ss.SSS}%thread%-5level%logger{36}%msg" } } appenderList.add("EMAIL") } appender("Console", ConsoleAppender) { encoder(PatternLayoutEncoder) { pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" } } logger("org.celllife", INFO) scan("30 seconds") root(ERROR, ["Console", "EMAIL"]) -- 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-228) Revert to previous configuration if configuration fails during scan
by Simon Kelly (JIRA) 10 Feb '11

10 Feb '11

Revert to previous configuration if configuration fails during scan ------------------------------------------------------------------- Key: LBCLASSIC-228 URL: http://jira.qos.ch/browse/LBCLASSIC-228 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.26 Reporter: Simon Kelly Assignee: Logback dev list With logback configured to scan for changes in the config file, if the change causes an error in the configuration (e.g. syntax of undefined property) the logger remains unconfigured and does not perform any future scans. The only way to reconfigure the logger is to restart the applicaiton (in the case of a webapp). It would be good for logback to be able to recover from such an error by reverting to the previous configuration so that logging continues and also the error in the config file may be fixed. -- 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: (LBCORE-120) ArrayIndexOutOfBoundsException when using Oracle driver ojdbc6 with DBAppender
by Manuel Kueblboeck (JIRA) 09 Feb '11

09 Feb '11

ArrayIndexOutOfBoundsException when using Oracle driver ojdbc6 with DBAppender ------------------------------------------------------------------------------ Key: LBCORE-120 URL: http://jira.qos.ch/browse/LBCORE-120 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.17 Environment: Windows XP, Oracle Database 11g Release 11.1.0.0.0, jdk1.6.0_16 Reporter: Manuel Kueblboeck Assignee: Logback dev list Priority: Minor When using the Oracle driver ojdbc6 (11.1.0.7.0) an ArrayIndexOutOfBoundsException occurs when trying to write a log message to the database (see stacktrace below). I am using ch.qos.logback.core.db.DriverManagerConnectionSource in my logback.xml. When using ojdbc14 (10.2.0.4), this works fine. 07:31:43,997 |-ERROR in ch.qos.logback.classic.db.DBAppender[LogDB] - problem appending event java.lang.ArrayIndexOutOfBoundsException: 10 at java.lang.ArrayIndexOutOfBoundsException: 10 at at oracle.jdbc.driver.OracleSql.computeBasicInfo(OracleSql.java:950) at at oracle.jdbc.driver.OracleSql.getSqlKind(OracleSql.java:623) at at oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:1212) at at oracle.jdbc.driver.T4CPreparedStatement.<init>(T4CPreparedStatement.java:28) at at oracle.jdbc.driver.T4CDriverExtension.allocatePreparedStatement(T4CDriverExtension.java:68) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:3140) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:3042) at at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:6022) at at ch.qos.logback.core.db.DBAppenderBase.append(DBAppenderBase.java:90) at at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:87) at at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:271) at at ch.qos.logback.classic.Logger.callAppenders(Logger.java:258) at at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:440) at at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:394) at at ch.qos.logback.classic.Logger.debug(Logger.java:521) at at nz.co.integrationworks.reporting.AbstractReporter.log(AbstractReporter.java:37) at at nz.co.integrationworks.reporting.AbstractReporter.log(AbstractReporter.java:29) at at nz.co.integrationworks.reporting.BusinessLoggerManualTest.main(BusinessLoggerManualTest.java:28) -- 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: (LBCLASSIC-183) Tomcat reports SEVERE ThreadLocal issues upon shutdown
by Anthony Whitford (JIRA) 01 Feb '11

01 Feb '11

Tomcat reports SEVERE ThreadLocal issues upon shutdown ------------------------------------------------------ Key: LBCLASSIC-183 URL: http://jira.qos.ch/browse/LBCLASSIC-183 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.18 Environment: Tomcat 6.0.24, JDK 6, Windows or Solaris Reporter: Anthony Whitford Assignee: Logback dev list I have a webapp that uses Logback, deployed on a Tomcat instance. Upon shutdown, Tomcat reports this and doesn't completely shut down: SEVERE: A web application created a ThreadLocal with key of type [org.slf4j.impl.CopyOnInheritThreadLocal] (value [org.slf4j.impl.CopyOnInheritThreadLocal@1bb35 b]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Feb 3, 2010 10:49:22 PM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap SEVERE: A web application created a ThreadLocal with key of type [null] (value [ch.qos.logback.core.UnsynchronizedAppenderBase$1@10e2558]) and a value of type [java.lang.Boolean] (value [false]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed. Is LogBack leaking resources? -- 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

7 12

[JIRA] Created: (LBSITE-38) Reference the configuration chapter from onJoran and vice versa
by Ceki Gulcu (JIRA) 11 Jan '11

11 Jan '11

Reference the configuration chapter from onJoran and vice versa --------------------------------------------------------------- Key: LBSITE-38 URL: http://jira.qos.ch/browse/LBSITE-38 Project: logback-site Issue Type: Task Components: Documentation Reporter: Ceki Gulcu Assignee: Logback dev list The onJoran chapter provides low level details about joran and the configuration chapter shows usage of joran. each chapter should reference the other for completeness. -- 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-160) TimeBasedRollingWithArchiveRemovalTest keeps failing
by Joern Huxhorn (JIRA) 29 Dec '10

29 Dec '10

TimeBasedRollingWithArchiveRemovalTest keeps failing ---------------------------------------------------- Key: LBCORE-160 URL: http://jira.qos.ch/browse/LBCORE-160 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: unspecified Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_20 Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac" Reporter: Joern Huxhorn Assignee: Logback dev list Revision: 15b5239b5d583a86877b79e77336729317cf2dc0 The following error happens every time I try to build Logback: dailySizeBasedRollover(ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest) Time elapsed: 0.443 sec <<< ERROR! java.util.concurrent.TimeoutException at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:228) at java.util.concurrent.FutureTask.get(FutureTask.java:91) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest.waitForCompression(TimeBasedRollingWithArchiveRemovalTest.java:216) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest.doRollover(TimeBasedRollingWithArchiveRemovalTest.java:206) at ch.qos.logback.core.rolling.TimeBasedRollingWithArchiveRemovalTest.dailySizeBasedRollover(TimeBasedRollingWithArchiveRemovalTest.java:146) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) -- 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: (LBCLASSIC-113) Nullpointer
by Mathias Bogaert (JIRA) 23 Dec '10

23 Dec '10

Nullpointer ----------- Key: LBCLASSIC-113 URL: http://jira.qos.ch/browse/LBCLASSIC-113 Project: logback-classic Issue Type: Bug Components: Other Reporter: Mathias Bogaert Assignee: Logback dev list Priority: Critical java.lang.NullPointerException at ch.qos.logback.classic.Logger.callTurboFilters(Logger.java:769) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:641) [logback-classic-0.9.15.jar:na] at ch.qos.logback.classic.Logger.isTraceEnabled(Logger.java:637) [logback-classic-0.9.15.jar:na] at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:198) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:905) [hibernate-core-3.3.0.SP1.jar:3.3.0.SP1] Hibernate calls if ( log.isTraceEnabled() ). -- 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 3