July 2010 - logback-dev - mailman3.qos.ch

[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

[JIRA] Created: (LBACCESS-10) Servlet input stream gets corrupted
by Augusto (JIRA) 16 Nov '10

16 Nov '10

Servlet input stream gets corrupted ----------------------------------- Key: LBACCESS-10 URL: http://jira.qos.ch/browse/LBACCESS-10 Project: logback-access Issue Type: Bug Components: Other Affects Versions: 0.9.17 Environment: Windows 7 - java 1.6.0_16-b01 - Hightide 6.1H10 Windows 7 - java 1.6.0_16-b01 - Tomcat 6.0.16 Solaris 5.10 - java 1.6.0_16 - Hightide 6.1H10 Reporter: Augusto Assignee: Logback dev list The request.inputStream() is wrapped in a TeeServletInputStreamm but this class fails to pass all the data in the original input stream to the servlets. In my tests is passes properly between 4 and 8kb of data and later it just return zeros instead of the characters. I'm attaching a very simple webapp that writes the input stream of a POST request into a file to demonstrate the 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 4

[JIRA] Created: (LBCLASSIC-130) Multiple resource warning is not appropriate for logback-test.xml
by Jon Vincent (JIRA) 20 Oct '10

20 Oct '10

Multiple resource warning is not appropriate for logback-test.xml ----------------------------------------------------------------- Key: LBCLASSIC-130 URL: http://jira.qos.ch/browse/LBCLASSIC-130 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.14, 0.9.15, 0.9.16 Reporter: Jon Vincent Assignee: Logback dev list Priority: Minor When LBCLASSIC-85 was fixed, it also applied to logback-test.xml. Unfortunately, some IDEs (such as Eclipse) include the test classpath for all modules in a multi-module project -- which means that it's nearly impossible to avoid having multiple logback-test.xml files on the classpath if one project depends on another when running tests in Eclipse. Every test in the project will therefore emit this warning when run from the IDE. Is it possible to have the ContextInitializer only emit this warning for logback.xml, and not logback-test.xml? This would avoid a spurious/unactionable warning for developers using Eclipse. -- 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

5 14

[JIRA] Created: (LBCORE-114) Lifecycle.stop is not called for policy objects
by Anders Wallgren (JIRA) 14 Oct '10

14 Oct '10

Lifecycle.stop is not called for policy objects ----------------------------------------------- Key: LBCORE-114 URL: http://jira.qos.ch/browse/LBCORE-114 Project: logback-core Issue Type: Bug Affects Versions: 0.9.17 Reporter: Anders Wallgren Assignee: Logback dev list TriggeringPolicy implements Lifecycle, and start is called during configuration. However, when the context is shut down, stop is not called. -- 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-216) java.lang.NullPointerException in ThrowableProxyUtil.java:42
by Luciano Canè (JIRA) 13 Oct '10

13 Oct '10

java.lang.NullPointerException in ThrowableProxyUtil.java:42 ------------------------------------------------------------ Key: LBCLASSIC-216 URL: http://jira.qos.ch/browse/LBCLASSIC-216 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.24 Environment: IDE WebSphere 6.1 , IBM JDK 1.5 Reporter: Luciano Canè Assignee: Logback dev list {code:title=test example} import org.slf4j.LoggerFactory; public class TestLogBack { public TestLogBack() { super(); } public static void main(String[] args) { TestLogBack test = new TestLogBack(); test.execute(); } private void execute() { org.slf4j.Logger logger = LoggerFactory.getLogger(TestLogBack.class); //test try { throw new TestLogBackException("Test: getStackTrace() return null"); //$NON-NLS-1$ } catch (Throwable t) { logger.error("Messaggio di Test di {}", t.getMessage(), t); //$NON-NLS-1$ } } class TestLogBackException extends Exception { private static final long serialVersionUID = 1L; public TestLogBackException(String message) { super(message); } @Override public StackTraceElement[] getStackTrace() { return null; } } } {code} {code:title=exception stack trace} Exception in thread "main" java.lang.NullPointerException at ch.qos.logback.classic.spi.ThrowableProxyUtil.steArrayToStepArray(ThrowableProxyUtil.java:42) at ch.qos.logback.classic.spi.ThrowableProxy.<init>(ThrowableProxy.java:35) at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:123) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:469) at ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:462) at ch.qos.logback.classic.Logger.error(Logger.java:580) at z_prove.logback.TestLogBack.execute(TestLogBack.java:28) at z_prove.logback.TestLogBack.main(TestLogBack.java:13) {code} -- 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: (LBCORE-154) Use of default values in appender-refs
by David Harrigan (JIRA) 13 Oct '10

13 Oct '10

Use of default values in appender-refs -------------------------------------- Key: LBCORE-154 URL: http://jira.qos.ch/browse/LBCORE-154 Project: logback-core Issue Type: Improvement Components: Appender Environment: All Reporter: David Harrigan Assignee: Logback dev list This is referenced also here: http://old.nabble.com/Appender-Ref-Default-Value-to28605941.html Please can we have the ability to specify default values for appender-refs. I have a use case where we need to "bake-in" the appender during build-time. I can do this at the moment for logger level by bringing in a property file (called override.properties) that can reset the logging level (which is dependent on the deployment environment and other factors). Here is a little example: <property resource="override.properties" /> <logger name="bar.foo" level="${bar.foo.log.level:-info}" additivity="false"> <appender-ref ref="console"/> </logger> The bar.foo.log.level is defined in the override.properties file. The correct file gets inserted for each build type. I would like to do the following as well: <logger name="bar.foo" level="${bar.foo.log.level:-info}" additivity="false"> <appender-ref ref="${bar.foo.log.appender:-console}"/> </logger> So that I can tell the override where to log to (console for development or log file, or smtp, or jms, or db for other environments). This would be so neato if implemented :-) Thank you. -=david=- -- 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 8