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

[JIRA] Created: (LBCLASSIC-323) SMTPAppender does not send messages
by Lutz Huehnken (JIRA) 07 May '12

07 May '12

SMTPAppender does not send messages ----------------------------------- Key: LBCLASSIC-323 URL: http://jira.qos.ch/browse/LBCLASSIC-323 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 1.0.0 Environment: JDK 1.5 FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #0: Tue Apr 15 17:37:45 CEST 2008 amd64 Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01) Java HotSpot(TM) 64-Bit Server VM (build diablo-1.5.0_07-b01, mixed mode) Reporter: Lutz Huehnken Assignee: Logback dev list After upgrading from 0.9.30 to 1.0.0, the ch.qos.logback.classic.net.SMTPAppender seizes to work. It just does not send any messages anymore. This behaviour has apparently been observed by others as well and is also described in this thread: http://old.nabble.com/SMTPAppender-mail-not-sent-%28logback-1.0.0%2C-JDK-1.… It resumes working when - while making no other changes - logback is downgraded to version 0.9.30 -- 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: (LBACCESS-28) Could not find status manager
by seenimurugan shanmugam (JIRA) 05 May '12

05 May '12

Could not find status manager ----------------------------- Key: LBACCESS-28 URL: http://jira.qos.ch/browse/LBACCESS-28 Project: logback-access Issue Type: Bug Affects Versions: 0.9.30 Environment: tomcat 6.0.33 , mac lion os. Reporter: seenimurugan shanmugam Assignee: Logback dev list When access https://localhost:8443/lbAccessStatus i get this message on the screen ( Could not find status manager ). my configuration details. ===================== server -- tomcat 6.0.33 os ----- Mac OS X (Lion) web.xml config is ============== <servlet> <servlet-name>AccessViewStatusMessages</servlet-name> <servlet-class>ch.qos.logback.access.ViewStatusMessagesServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>AccessViewStatusMessages</servlet-name> <url-pattern>/lbAccessStatus</url-pattern> </servlet-mapping> logback-access.xml on tomcat/conf dirctory ================================== <?xml version="1.0" encoding="UTF-8"?> <configuration>  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" /> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>access.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>access.%d{yyyy-MM-dd}.log.zip</fileNamePattern> </rollingPolicy> <encoder> <pattern>combined</pattern> </encoder> </appender> <appender-ref ref="FILE" /> </configuration> jar installed in tomcat/lib directory are ============================== logback-access-0.9.30.jar logback-core-0.9.30.jar when i run my web application in netbeans i can see the logback status message as ==================================================================== 18:43:39,490 |-INFO in ch.qos.logback.access.tomcat.LogbackValve[Catalina] - filename property not set. Assuming [/Users/seeni/software/apache-tomcat-6.0.33/conf/logback-access.xml] 18:43:39,556 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - Ignoring debug attribute. 18:43:39,559 |-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Adding status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener] 18:43:39,576 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 18:43:39,581 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] 18:43:39,622 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use zip compression 18:43:39,624 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern access.%d{yyyy-MM-dd}.log for the active file 18:43:39,632 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'access.%d{yyyy-MM-dd}.log.zip'. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Mon Nov 07 18:42:34 GMT 2011 18:43:39,635 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.access.PatternLayoutEncoder] for [encoder] property 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: access.log 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [access.log] 18:43:39,660 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to ch.qos.logback.access.tomcat.LogbackValve[Catalina] 18:43:39,661 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - End of configuration. 18:43:39,662 |-INFO in ch.qos.logback.access.joran.JoranConfigurator@4e299813 - Registering current configuration as safe fallback point 18:43:39,490 |-INFO in ch.qos.logback.access.tomcat.LogbackValve[Catalina] - filename property not set. Assuming [/Users/seeni/software/apache-tomcat-6.0.33/conf/logback-access.xml] 18:43:39,556 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - Ignoring debug attribute. 18:43:39,559 |-INFO in ch.qos.logback.core.joran.action.StatusListenerAction - Adding status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener] 18:43:39,576 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.rolling.RollingFileAppender] 18:43:39,581 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [FILE] 18:43:39,622 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use zip compression 18:43:39,624 |-INFO in c.q.l.core.rolling.TimeBasedRollingPolicy - Will use the pattern access.%d{yyyy-MM-dd}.log for the active file 18:43:39,632 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - The date pattern is 'yyyy-MM-dd' from file name pattern 'access.%d{yyyy-MM-dd}.log.zip'. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Roll-over at midnight. 18:43:39,633 |-INFO in c.q.l.core.rolling.DefaultTimeBasedFileNamingAndTriggeringPolicy - Setting initial period to Mon Nov 07 18:42:34 GMT 2011 18:43:39,635 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.access.PatternLayoutEncoder] for [encoder] property 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - Active log file name: access.log 18:43:39,659 |-INFO in ch.qos.logback.core.rolling.RollingFileAppender[FILE] - File property is set to [access.log] 18:43:39,660 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [FILE] to ch.qos.logback.access.tomcat.LogbackValve[Catalina] 18:43:39,661 |-INFO in ch.qos.logback.access.joran.action.ConfigurationAction - End of configuration. 18:43:39,662 |-INFO in ch.qos.logback.access.joran.JoranConfigurator@4e299813 - Registering current configuration as safe fallback point logback status looks ok. But could not see the status on browser when i access https://localhost:8443/lbClassicStatus , it's works fine but not https://localhost:8443/lbAccessStatus I spent a whole day looking at BasicStatusManager class and all the other stuff , but no luck. is there anything i am missing or is it really a bug? Thanks. -- 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 15

[JIRA] Created: (LBCORE-234) write a special line as the first line in any log file so that the file can be automatically parsed by a tool
by James Strachan (JIRA) 03 May '12

03 May '12

write a special line as the first line in any log file so that the file can be automatically parsed by a tool ------------------------------------------------------------------------------------------------------------- Key: LBCORE-234 URL: http://jira.qos.ch/browse/LBCORE-234 Project: logback-core Issue Type: New Feature Components: Layout Affects Versions: 0.9.9 Reporter: James Strachan Assignee: Logback dev list So there's a few tools out there for parsing log files; most of them require the user to create a regex or find the right line of some config file to figure out what the Pattern layout expression was used to create the log file. The problem with these is the regex/patterns are quite brittle; its easy for code/dependencies to change and new log configuration to become effective or for users to not know the correct config/pattern for a file. (Its easy to have quite a few log configuration files in a tarball/war/bundle and not be quite sure which one is really active in a container for example). A simpler idea would be to (optionally but hopefully by default) output the first line of every log file some kind of well known first line (which can easily be excluded by tools that grep for stuff or whatever) which describes the pattern layout thats being used to write the file - so files generated by logback would be automatically parseable by a generic tool. Indeed it'd be nice to have such a tool; so you can easily load a file and turn it into ILoggingEvent objects by parsing the first line... e.g. imaging if all the files (including rolling logs and whatnot) looked like this... {code} #logback.ConversionPattern=%d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n 11:52:08,267 | INFO | FelixStartLevel | BlueprintExtender | rint.container.BlueprintExtender 124 | 9 - org.apache.aries.blueprint - 0.3.1 | No quiesce support is available, so blueprint components will not participate in quiesce operations 11:52:08,400 | INFO | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 266 | 9 - org.apache.aries.blueprint - 0.3.1 | Bundle org.apache.karaf.management is waiting for namespace handlers 11:52:08,704 | INFO | FelixStartLevel | jmx | ? ? | 27 - org.apache.aries.jmx - 0.3.0 | Starting JMX OSGi agent {code} so via a simple bit of code the first line (or all lines starting with #logback.) could be parsed to figure out the format of the file; then the rest of the file could be turned into ILogEvents and passed into tools - or rendered easily in the logback eclipse plugin for example. Folks could even reverse engineer log formats and make sure other framework/tools/apps output the correct log format up front. Then dev/ops can just 'open a log' and its not just text with error prone regex/parsing expressions that have to be guessed but a kinda 'self describing log markup' -- 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 12

[JIRA] Created: (LBCLASSIC-256) java.util.logging propagated level changes are lost because of race condition with garbage collection
by Samuel Stanojevic (JIRA) 03 May '12

03 May '12

java.util.logging propagated level changes are lost because of race condition with garbage collection ----------------------------------------------------------------------------------------------------- Key: LBCLASSIC-256 URL: http://jira.qos.ch/browse/LBCLASSIC-256 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Environment: win7 64-bit, bootstrapped in a Tomcat server Reporter: Samuel Stanojevic Assignee: Logback dev list Attachments: LevelChangePropagator.java I have bootstrapped logback in my Tomcat server, and have setup JUL to redirect logging requests to SLF4J by adding the following in my logging.properties: .handlers = org.slf4j.bridge.SLF4JBridgeHandler Anyways, my setup works pretty nicely. The problem is when I try to activate the JUL LevelChangePropagator, the info doesn't quite propagate as expected. Here is my config: <configuration debug="true"> <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator"> <resetJUL>true</resetJUL> </contextListener> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> <target>System.out</target> </appender> <root level="ERROR"> <appender-ref ref="STDOUT" /> </root> <logger name="test.propagation" level="TRACE"/>  </configuration> The problem is that if my app tries to do: java.util.logging.Logger.getLogger("test.propagation").fine("hello world"); ..., it doesn't print. I have confirmed that the bug is because, even though the LevelChangePropagator class does propagate the level change info to JUL, it fails to keep a strong reference to the logger that it just changed. By not keeping a strong reference, and because the JUL LogManager only keeps WeakReferences to loggers, then the GC has time to clear out the change before the app's first attempt to use the logger. (see java.util.logging.LogManager#addLogger where the javadoc says "The application should retain its own reference to the Logger object to avoid it being garbage collected. The LogManager may only retain a weak reference") To test my hunch, I patched the LevelChangePropagator class by adding a global hashset of java.util.logging.Logger, and I systematically add the loggers to the hashset in the method "propagate(logger,level)". After this patch, my logging started working as expected. My fix may not be the best, and may have implications that I did not think about, but I think something along those lines needs to be done to fix 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

5 7

[JIRA] Created: (LBCORE-243) Return ImmediateFlush and perhaps buffering options to FileAppender
by Petr H (JIRA) 03 May '12

03 May '12

Return ImmediateFlush and perhaps buffering options to FileAppender ------------------------------------------------------------------- Key: LBCORE-243 URL: http://jira.qos.ch/browse/LBCORE-243 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 1.0.0 Reporter: Petr H Assignee: Logback dev list Based on the "log4j performance comparison" discussion in the logback-user mailing list: http://old.nabble.com/log4j-performance-comparison-td31183677.html I'd like to see at least the ImmediateFlush option back as it causes really big difference in writing performance at our systems with heavy logging activity. Last logback release with ImmediateFlush option is 0.9.18 and this is the one we have to stay at due to performance reasons. We can't afford to upgrade to later logback release or switch ImmediateFlush to true as it makes some of our systems practically unusable. The best option seems to be the use of FileWriter with the possibility to set the ImmediateFlush option and also buffering (wrapping with BufferedWriter and use of BufferedIO + BufferSize options) can help a little. -- 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] Created: (LBCLASSIC-234) CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide
by uri unger (JIRA) 25 Apr '12

25 Apr '12

CLONE -Excessive synchronization in ReconfigureOnChangeFilter.decide -------------------------------------------------------------------- Key: LBCLASSIC-234 URL: http://jira.qos.ch/browse/LBCLASSIC-234 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Reporter: uri unger Assignee: Ceki Gulcu The synchronization in ReconfigureOnChangeFilter.decide hurts scalability. It seems unnecessary to serialize the code in changeDetected -- it should be possible to use atomic updates of nextCheck and lastModified and only serialize the actual reconfiguration. -- 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 18

[JIRA] Created: (LBCORE-221) Error in FileNamePattern::toRegex for index (Integer)
by Dieter Mueller (JIRA) 25 Apr '12

25 Apr '12

Error in FileNamePattern::toRegex for index (Integer) ----------------------------------------------------- Key: LBCORE-221 URL: http://jira.qos.ch/browse/LBCORE-221 Project: logback-core Issue Type: Bug Components: Pattern, Rolling Affects Versions: 0.9.29 Reporter: Dieter Mueller Assignee: Logback dev list Priority: Minor Deletion of old archived logs on rolling failes for index > 99. We have a process which logs much, which results in more than 99 log files per day (config below), e.g. snowball_POLL_MSG_SRV_xdebug-old-2011-09-13.110.log.zip. On rolling event, only the first 99 were deleted, due to bug in FileNamePattern::toRegex for index (Integer): regEx: \d{1,2) which means digits with max length of 2. We need at least 3 digits: regEx: \d{1,3) better 4? ;-) Workarounds like increasing file size, or hourly-rollover to hold index lower than 100 are not very wellcomed. Thanks in advance, Dieter Mueller. config: <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">  <fileNamePattern>${log.vm.file.prefix}_xdebug-old-%d{yyyy-MM-dd}.%i.log.zip</fileNamePattern> <maxHistory>1</maxHistory> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>20MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> -- 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-169) RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory
by Tomasz Nurkiewicz (JIRA) 24 Apr '12

24 Apr '12

RollingFileAppender/TimeBasedRollingPolicy failing to ZIP files in different directory -------------------------------------------------------------------------------------- Key: LBCORE-169 URL: http://jira.qos.ch/browse/LBCORE-169 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.24 Reporter: Tomasz Nurkiewicz Assignee: Logback dev list When using ZIP feature to compress old log files, Logback does not allow to put ZIP files in different directory like in this example: <file>logs\server.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>logs\arch\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> </rollingPolicy> Running the attached test maven project (it takes 1 minute to run) will create server.log3560979839057.tmp (or similar) temporary file instead of ZIP file in /arch subdirectory (preferably this directory should be created if not exists). If fileNamePattern in rollingPolicy is changed to: "logs\server.%d{yyyy-MM-dd_HHmm}.log.zip" everything works as expected. The root of this issue is to be able to automatically ZIP files AND archive them in different directory. It would be great to be able to use date placeholders in folder names, for instance: <fileNamePattern>logs\arch-%d{yyyy-MM}\server.%d{yyyy-MM-dd_HHmm}.log.zip</fileNamePattern> so that Logback would automatically create folders for each month with ZIPped files. -- 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

8 9

[JIRA] Created: (LBCORE-84) Typo in PropertyAction
by Michael Franz (JIRA) 24 Apr '12

24 Apr '12

Typo in PropertyAction ---------------------- Key: LBCORE-84 URL: http://jira.qos.ch/browse/LBCORE-84 Project: logback-core Issue Type: Bug Components: Joran Affects Versions: 0.9.14 Reporter: Michael Franz Assignee: Logback dev list Priority: Trivial The following message is printed |-WARN in ch.qos.logback.core.joran.action.PropertyAction - [substitutionProperty] element has been deprecated. Plase use the [property] element instead. There an 'e' missing in "Please". -- 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] Created: (LBCLASSIC-309) Groovy-config fails without outside code noticing
by Endre Stølsvik (JIRA) 10 Apr '12

10 Apr '12

Groovy-config fails without outside code noticing ------------------------------------------------- Key: LBCLASSIC-309 URL: http://jira.qos.ch/browse/LBCLASSIC-309 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: unspecified Environment: na Reporter: Endre Stølsvik Assignee: Logback dev list Priority: Minor [As reported on the user-list, where I was requested to make a bug report] This groovy-file ...: import ch.qos.logback.classic.PatternLayout import ch.qos.logback.core.ConsoleAppender import ch.qos.logback.core.encoder.LayoutWrappingEncoder appender("STDOUT", ConsoleAppender) { encoder(LayoutWrappingEncoder) { layout(PatternLayout) { pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{55}.%M.%L - %msg%n" } } } root(ALL, ["STDOUT"]) ... apparently crashes the configuration as such: Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported exception: groovy.lang.MissingPropertyException: No such property: ALL for class: Script1 at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:50) at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:231) at Script1.run(Script1.groovy:13) at Script1$run.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:42) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:59) at ch.qos.logback.classic.gaffer.GafferConfigurator$run.callCurrent(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:46) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:133) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141) at ch.qos.logback.classic.gaffer.GafferConfigurator.run(GafferConfigurator.groovy:37) at ch.qos.logback.classic.gaffer.GafferUtil.runGafferConfiguratorOn(GafferUtil.java:44) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:67) 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:128) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279) at XYZ.doLogConfig(XYZ.java:40) at XYZ.main(XYZ:169) The problem is obviously, as the error message states, the not-defined property "ALL". *The problem I am reporting is that this isn't caught*. The console-dump happens in the "We should never get here" catch block below: void init() { try { try { new ContextInitializer(defaultLoggerContext).autoConfig(); } catch (JoranException je) { Util.report("Failed to auto configure default logger context", je); } StatusPrinter.printInCaseOfErrorsOrWarnings(defaultLoggerContext); contextSelectorBinder.init(defaultLoggerContext, KEY); initialized = true; } catch (Throwable t) { // we should never get here Util.report("Failed to instantiate [" + LoggerContext.class.getName() + "]", t); } } Notice that the StatusManager does not know that the config failed: 13:32:07,643 |-INFO in ch.qos.logback.classic.LoggerContext[Emma logcontext] - Found resource [logback.groovy] at [file:/XYZ/target/classes/logback.groovy] 13:32:08,807 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@2111e072 - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 13:32:08,809 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@2111e072 - Naming appender as [STDOUT] -- 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