December 2008 - logback-dev

Logback 0.9.14
by Szel, Zoltan (IT) 11 Dec '08

11 Dec '08

Hi, could you please tell me when logback 0.9.14 is going to be released? The http://jira.qos.ch/browse/LBCORE-78 issue is too severe for me which blocks me using 0.9.13. Thanks in advance! Kind Regards, Zoltan Szel Morgan Stanley | Technology Lechner Odon fasor 8 | Floor 07 Budapest, 1095 Phone: +36 1 881-3978 Zoli.Szel(a)MorganStanley.com<mailto:Zoli.Szel@MorganStanley.com> -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

2 2

svn commit: r2078 - logback/tags/release_0.9.14M0/trunk
by noreply.ceki＠qos.ch 11 Dec '08

11 Dec '08

Author: ceki Date: Thu Dec 11 17:08:21 2008 New Revision: 2078 Added: logback/tags/release_0.9.14M0/trunk/ - copied from r2077, /logback/trunk/ Log: tagging for Szel Zoltan

1 0

svn commit: r2077 - logback/tags/release_0.9.14M0
by noreply.ceki＠qos.ch 11 Dec '08

11 Dec '08

Author: ceki Date: Thu Dec 11 17:07:14 2008 New Revision: 2077 Added: logback/tags/release_0.9.14M0/ Log: tagging for Szel Zoltan

1 0

r2076:
by Thorbjørn Ravn Andersen 11 Dec '08

11 Dec '08

I have logback/trunk checked out, and did a "svn update; mvn clean; mvn compile; mvn install" to get up to speed. The "mvn install" hangs - apparently in a test - with this being the last printed: Running ch.qos.logback.classic.net.SMTPAppender_SubethaSMTPTest [HEADER 11469 [main] DEBUG test ch.qos.logback.classic.net.SMTPAppender_SubethaSMTPTest - hello 11469 [main] ERROR test ch.qos.logback.classic.net.SMTPAppender_SubethaSMTPTest - en error java.lang.Exception: an exception at ch.qos.logback.classic.net.SMTPAppender_SubethaSMTPTest.smoke(SMTPAppender_SubethaSMTPTest.java:121) [test-classes/:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.5.0] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.5.0] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.5.0] at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0] at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) [junit-4.4.jar:na] at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) [junit-4.4.jar:na] at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) [junit-4.4.jar:na] at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) [junit-4.4.jar:na] at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) [junit-4.4.jar:na] at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) [junit-4.4.jar:na] at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) [junit-4.4.jar:na] at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) [junit-4.4.jar:na] at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) [junit-4.4.jar:na] at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) [junit-4.4.jar:na] at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) [junit-4.4.jar:na] at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) [junit-4.4.jar:na] at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) [surefire-junit4-2.4.2.jar:2.4.2] at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) [surefire-api-2.4.2.jar:2.1] at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) [surefire-api-2.4.2.jar:2.1] at org.apache.maven.surefire.Surefire.run(Surefire.java:177) [surefire-api-2.4.2.jar:2.1] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [na:1.5.0] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [na:1.5.0] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [na:1.5.0] at java.lang.reflect.Method.invoke(Method.java:585) [na:1.5.0] at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) [surefire-booter-2.4.2.jar:na] at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) [surefire-booter-2.4.2.jar:na] FOOTER Before digging in, is there a step I have missed? -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

3 3

[JIRA] Created: (LBCORE-78) Compression with TimeBasedRollingPolicy leaks a thread which blocks the application to shutdown + leads to severe memory leak in webapps
by Szel Zoltan (JIRA) 10 Dec '08

10 Dec '08

Compression with TimeBasedRollingPolicy leaks a thread which blocks the application to shutdown + leads to severe memory leak in webapps ---------------------------------------------------------------------------------------------------------------------------------------- Key: LBCORE-78 URL: http://jira.qos.ch/browse/LBCORE-78 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.13 Environment: 1.5,1.6 JDK Reporter: Szel Zoltan Assignee: Logback dev list Priority: Blocker Hi, the TimeBasedRollingPolicy uses the AsynchronousCompressor class to perform the compression in a background thread. In the AsyncCompressor every compress creates a ThreadPool with one thread which is never stopped. After compression the thread will wait on a queue to be fed with new task which will never happen again and there is now chance to stop the thread manually, because the reference to the ExecutorService is lost. Because the thread is not stoped and it is not a deamon thread, the JVM can not shutdown. In web env this bug causes the leak of the application's classloader. A simple solution is to create a simple thread to perform the compression instead of using an ExecutorService. Regards, 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

2 2

svn commit: r2076 - logback/trunk/logback-core/src/main/java/ch/qos/logback/core/rolling/helper
by noreply.ceki＠qos.ch 10 Dec '08

10 Dec '08

Author: ceki Date: Wed Dec 10 17:29:23 2008 New Revision: 2076 Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/rolling/helper/AsynchronousCompressor.java Log: Fix LBCORE-78. AsynchronousCompressor shuts down the executor it created, thus avoiding a memory leak. Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/rolling/helper/AsynchronousCompressor.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/rolling/helper/AsynchronousCompressor.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/rolling/helper/AsynchronousCompressor.java Wed Dec 10 17:29:23 2008 @@ -13,7 +13,9 @@ public Future<?> compressAsynchronously() { ExecutorService executor = Executors.newScheduledThreadPool(1); - return executor.submit(new CompressionRunnable(compressor)); + Future<?> future = executor.submit(new CompressionRunnable(compressor)); + executor.shutdown(); + return future; } }

1 0

[JIRA] Resolved: (LBCLASSIC-39) no log messages after redeployment
by Ceki Gulcu (JIRA) 05 Dec '08

05 Dec '08

[ http://jira.qos.ch/browse/LBCLASSIC-39?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-39. --------------------------------- Fix Version/s: 0.9.13 Resolution: Cannot Reproduce I am marking this issue as CANNOT REPRODUCE. Please re-open it if it has not been corrected in 0.9.13. > no log messages after redeployment > ---------------------------------- > > Key: LBCLASSIC-39 > URL: http://jira.qos.ch/browse/LBCLASSIC-39 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: PC > Reporter: Ingo Siebert > Assignee: Logback dev list > Priority: Blocker > Fix For: 0.9.13 > > Attachments: jedi0.zip > > > Hi, > I use the JNDI switch for logback. > If I undeploy my application, the old JNDI context ist destroyed (it's a log messge). That's fine. > But I redeploy the same application with the same context name, no logging messages are displayed. That's very frustrating. > If I restart Tomcat6, then the deployed application comes up and i see the messages again. > The libs which are needed by my application are stored in the tomcat6/sharedLib folder. > Any idea why the messages are missing? > Ingo > This is my web.xml: > <filter> > <filter-name>LoggerContextFilter</filter-name> > <filter-class>ch.qos.logback.classic.selector.servlet.LoggerContextFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>LoggerContextFilter</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping> > <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> > </listener> >  > <listener> > <listener-class>ch.qos.logback.classic.selector.servlet.ContextDetachingSCL</listener-class> > </listener> > ... > <env-entry> > <description>JNDI logging context for this app</description> > <env-entry-name>logback/context-name</env-entry-name> > <env-entry-value>EIMContext-1</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> > <env-entry> > <description>URL for configuring logback context</description> > <env-entry-name>logback/configuration-resource</env-entry-name> > <env-entry-value>eim_logback.xml</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> -- 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 0

[JIRA] Updated: (LBCLASSIC-39) no log messages after redeployment
by Ceki Gulcu (JIRA) 05 Dec '08

05 Dec '08

[ http://jira.qos.ch/browse/LBCLASSIC-39?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu updated LBCLASSIC-39: -------------------------------- Attachment: jedi0.zip I have attached a test web-application. I have tested it with logback version 0.9.13. I can start and stop application without problems. I get the following output in catalina.out (see below). Consequently, I cannot reproduce the problem you describe. Several LoggerContext bugs were corrected in logback recently which explain the descrepancy. You please see if the problem you observed has been corrected in recent versions of logback? As a side note, you really should use SLF4J version 1.5.6 which solves a LoggerContext related issue. INFO: Dï¿½marrage de Coyote HTTP/1.1 sur http-9090 5 déc. 2008 19:39:06 org.apache.catalina.startup.Catalina start INFO: Server startup in 455 ms JEDI0 2008-12-05 19:39:10,828 DEBUG -in doGet() 19:39:10,734 |-INFO in ch.qos.logback.classic.selector.ContextJNDISelector@e61fd1 - Searching for [logback-jedi0.xml] 19:39:10,765 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 19:39:10,765 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 19:39:10,765 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CON] 19:39:10,781 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Popping appender named [CON] from the object stack 19:39:10,781 |-INFO in ch.qos.logback.classic.joran.action.JMXConfiguratorAction - begin 19:39:10,828 |-INFO in ch.qos.logback.classic.joran.action.LevelAction - root level set to DEBUG 19:39:10,828 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [CON] to Logger[root] About to detach context named jedi0 JEDI0 2008-12-05 19:39:26,531 WARN -Stopping logger context jedi0 JEDI0 2008-12-05 19:39:57,875 DEBUG -in doGet() 19:39:57,859 |-INFO in ch.qos.logback.classic.selector.ContextJNDISelector@e61fd1 - Searching for [logback-jedi0.xml] 19:39:57,875 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 19:39:57,875 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 19:39:57,875 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CON] 19:39:57,875 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Popping appender named [CON] from the object stack 19:39:57,875 |-INFO in ch.qos.logback.classic.joran.action.JMXConfiguratorAction - begin 19:39:57,875 |-INFO in ch.qos.logback.classic.joran.action.LevelAction - root level set to DEBUG 19:39:57,875 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [CON] to Logger[root] > no log messages after redeployment > ---------------------------------- > > Key: LBCLASSIC-39 > URL: http://jira.qos.ch/browse/LBCLASSIC-39 > Project: logback-classic > Issue Type: Bug > Components: Other > Affects Versions: unspecified > Environment: Operating System: Windows > Platform: PC > Reporter: Ingo Siebert > Assignee: Logback dev list > Priority: Blocker > Fix For: 0.9.13 > > Attachments: jedi0.zip > > > Hi, > I use the JNDI switch for logback. > If I undeploy my application, the old JNDI context ist destroyed (it's a log messge). That's fine. > But I redeploy the same application with the same context name, no logging messages are displayed. That's very frustrating. > If I restart Tomcat6, then the deployed application comes up and i see the messages again. > The libs which are needed by my application are stored in the tomcat6/sharedLib folder. > Any idea why the messages are missing? > Ingo > This is my web.xml: > <filter> > <filter-name>LoggerContextFilter</filter-name> > <filter-class>ch.qos.logback.classic.selector.servlet.LoggerContextFilter</filter-class> > </filter> > <filter-mapping> > <filter-name>LoggerContextFilter</filter-name> > <url-pattern>/*</url-pattern> > </filter-mapping> > <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> > </listener> >  > <listener> > <listener-class>ch.qos.logback.classic.selector.servlet.ContextDetachingSCL</listener-class> > </listener> > ... > <env-entry> > <description>JNDI logging context for this app</description> > <env-entry-name>logback/context-name</env-entry-name> > <env-entry-value>EIMContext-1</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> > <env-entry> > <description>URL for configuring logback context</description> > <env-entry-name>logback/configuration-resource</env-entry-name> > <env-entry-value>eim_logback.xml</env-entry-value> > <env-entry-type>java.lang.String</env-entry-type> > </env-entry> -- 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 0

svn commit: r2074 - in logback/trunk: logback-classic/src/main/java/ch/qos/logback/classic/selector logback-classic/src/test/java/ch/qos/logback/classic logback-core/src/main/java/ch/qos/logback/core
by noreply.ceki＠qos.ch 05 Dec '08

05 Dec '08

Author: ceki Date: Fri Dec 5 19:19:02 2008 New Revision: 2074 Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerContextDeadlockTest.java Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/selector/ContextJNDISelector.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/Context.java Log: - in ContextJNDISelector renamed contextMap as synchronizedContextMap - cosmetic changes in Context Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/selector/ContextJNDISelector.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/selector/ContextJNDISelector.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/selector/ContextJNDISelector.java Fri Dec 5 19:19:02 2008 @@ -46,13 +46,13 @@ */ public class ContextJNDISelector implements ContextSelector { - private final Map<String, LoggerContext> contextMap; + private final Map<String, LoggerContext> synchronizedContextMap; private final LoggerContext defaultContext; private static final ThreadLocal<LoggerContext> threadLocal = new ThreadLocal<LoggerContext>(); public ContextJNDISelector(LoggerContext context) { - contextMap = Collections + synchronizedContextMap = Collections .synchronizedMap(new HashMap<String, LoggerContext>()); defaultContext = context; } @@ -62,7 +62,7 @@ } public LoggerContext detachLoggerContext(String loggerContextName) { - return contextMap.remove(loggerContextName); + return synchronizedContextMap.remove(loggerContextName); } public LoggerContext getLoggerContext() { @@ -89,13 +89,13 @@ return defaultContext; } else { // Let's see if we already know such a context - LoggerContext loggerContext = contextMap.get(contextName); + LoggerContext loggerContext = synchronizedContextMap.get(contextName); if (loggerContext == null) { // We have to create a new LoggerContext loggerContext = new LoggerContext(); loggerContext.setName(contextName); - contextMap.put(contextName, loggerContext); + synchronizedContextMap.put(contextName, loggerContext); URL url = findConfigFileURL(ctx, loggerContext); if (url != null) { configureLoggerContextByURL(loggerContext, url); @@ -162,12 +162,12 @@ public List<String> getContextNames() { List<String> list = new ArrayList<String>(); - list.addAll(contextMap.keySet()); + list.addAll(synchronizedContextMap.keySet()); return list; } public LoggerContext getLoggerContext(String name) { - return contextMap.get(name); + return synchronizedContextMap.get(name); } /** @@ -176,7 +176,7 @@ * @return the number of managed contexts */ public int getCount() { - return contextMap.size(); + return synchronizedContextMap.size(); } /** Added: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerContextDeadlockTest.java ============================================================================== --- (empty file) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/LoggerContextDeadlockTest.java Fri Dec 5 19:19:02 2008 @@ -0,0 +1,68 @@ +/** + * Logback: the generic, reliable, fast and flexible logging framework. + * + * Copyright (C) 2000-2008, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. + */ +package ch.qos.logback.classic; + +import java.io.ByteArrayInputStream; + +import org.junit.After; +import org.junit.Before; +import org.junit.Test; + +import ch.qos.logback.classic.joran.JoranConfigurator; +import ch.qos.logback.core.joran.spi.JoranException; + +public class LoggerContextDeadlockTest { + + LoggerContext loggerContext = new LoggerContext(); + JoranConfigurator jc = new JoranConfigurator(); + GetLoggerThread getLoggerThread = new GetLoggerThread(loggerContext); + + @Before + public void setUp() throws Exception { + jc.setContext(loggerContext); + } + + @After + public void tearDown() throws Exception { + } + + @Test(timeout=20000) + public void testLBCLASSIC_81() throws JoranException { + + + getLoggerThread.start(); + for (int i = 0; i < 500; i++) { + ByteArrayInputStream baos = new ByteArrayInputStream(new String( + "<configuration><root level=\"DEBUG\"/></configuration>").getBytes()); + jc.doConfigure(baos); + } + } + + class GetLoggerThread extends Thread { + + final LoggerContext loggerContext; + GetLoggerThread(LoggerContext loggerContext) { + this.loggerContext = loggerContext; + } + @Override + public void run() { + for (int i = 0; i < 10000; i++) { + if(i % 100 == 0) { + try { + Thread.sleep(1); + } catch (InterruptedException e) { + } + } + loggerContext.getLogger("a" + i); + } + } + } + +} Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/Context.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/Context.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/Context.java Fri Dec 5 19:19:02 2008 @@ -1,11 +1,11 @@ /** - * LOGBack: the reliable, fast and flexible logging library for Java. - * - * Copyright (C) 1999-2006, QOS.ch - * - * This library is free software, you can redistribute it and/or - * modify it under the terms of the GNU Lesser General Public License as - * published by the Free Software Foundation. + * Logback: the generic, reliable, fast and flexible logging framework. + * + * Copyright (C) 2000-2008, QOS.ch + * + * This library is free software, you can redistribute it and/or modify it under + * the terms of the GNU Lesser General Public License as published by the Free + * Software Foundation. */ package ch.qos.logback.core;

1 0

[JIRA] Created: (LBCLASSIC-81) Deadlock while configuring at runtime and requesting a new logger
by Holger Mense (JIRA) 05 Dec '08

05 Dec '08

Deadlock while configuring at runtime and requesting a new logger ----------------------------------------------------------------- Key: LBCLASSIC-81 URL: http://jira.qos.ch/browse/LBCLASSIC-81 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.11 Environment: Windows XP Sun JDK 1.5.0_15 Logback 0.9.11 Reporter: Holger Mense Assignee: Logback dev list Priority: Critical In a multithreaded environment a request of a logger instance can led to a deadlock, when another thread tries to apply a new configuration. In GenericConfigurator.doConfigure(InputSource):97 a lock is set on a Context instance. Then the new configuration will be applied. During this, a lock on the logger is required. When now a new logger instance is requested by LoggerFactory, LoggerContext.getLogger(String) is called. The operation sets a lock on the root logger to create a new child logger. At the end the method LoggerContext.incSize() is called to increase the number of entries in the loggerCache. This method is declared as "synchronized" and needs a lock on LoggerContext. Requesting a new logger instance while starting a reconfiguration of logback leds to a deadlock. LoggerContext.incSize() waits for a lock of the context (which is locked by GenericConfigurator), while waiting for lock of logger in Logger.setLevel() - which is locked by LoggerContext. For further information, see the thread dump: ManagedService Update Queue@5, priority=5, in group 'main', status: 'MONITOR' blocks Start Level Event Dispatcher@6 waiting for Start Level Event Dispatcher@6 at ch.qos.logback.classic.Logger.setLevel(Logger.java:188) at ch.qos.logback.classic.joran.action.LoggerAction.begin(LoggerAction.java:63) at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:262) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:136) at ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:118) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:36) at ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:321) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:98) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:74) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:55) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:48) Start Level Event Dispatcher@6 daemon, priority=5, in group 'main', status: 'MONITOR' blocks ManagedService Update Queue@5 waiting for ManagedService Update Queue@5 at ch.qos.logback.classic.LoggerContext.incSize(LoggerContext.java:153) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:142) at ch.qos.logback.classic.LoggerContext.getLogger(LoggerContext.java:46) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:161) at org.slf4j.bridge.SLF4JBridgeHandler.getSLF4JLogger(SLF4JBridgeHandler.java:149) at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:234) at java.util.logging.Logger.log(Logger.java:452) at java.util.logging.Logger.doLog(Logger.java:474) at java.util.logging.Logger.log(Logger.java:497) at java.util.logging.Logger.info(Logger.java:1.016) A quick fix is to set a lock on the LoggerContext in LoggerContext.getLogger(String). I am not sure, if this is the best solution, but it seems to work. -- 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