[ http://jira.qos.ch/browse/LBCLASSIC-265?page=com.atlassian.jira.plugin.syste... ] Ralph Goers commented on LBCLASSIC-265: --------------------------------------- The biggest consequence is that there is one extra level of indirection between the logger and the log level and filters. I tried every way I could think of to squeeze that and was surprised at how fickle the JVM appears to be. What I ended up with is extremely close to Logback's performance when calling isDebugEnabled a million times when the result is false. The second impact is what happens when you programmatically try to add a filter or appender to a logger. This is handled differently than processing a new configuration. In this case each change is done using thread-safe mechanisms since each change is done one at a time. I'm not going to go into the details, but this can get complicated. However, like SLF4J, the public API doesn't contain methods to do any of those operations.
Logging stops if invalid xml configuration is loaded by scanner ---------------------------------------------------------------
Key: LBCLASSIC-265 URL: http://jira.qos.ch/browse/LBCLASSIC-265 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Iwein Fuld Assignee: Logback dev list
When logging with scan="true" it is possible to stop all logging of an application silently. Steps to reproduce: - start an application with valid configuration and scan=true - break the logback.xml (leave out a quote or something) -> log goes silent Expected behavior: Logger fails to load new config and keeps running on the old configuration (like when valid xml, but invalid configuration is loaded).
-- 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