[ https://jira.qos.ch/browse/SLF4J-433?page=com.atlassian.jira.plugin.system.i... ] Joachim Durchholz commented on SLF4J-433: ----------------------------------------- In my book, it is okay to know the backend in the module that has the explicit dependency on Logback, and if that code is concentrated in one class. If you agree, you can just check Logback's health directly. If Logback does not offer an API to do that (I haven't checked), you could write a "canary Appender" that does not emit anything, just records whether it got log message, and check whether the messages arrive (you'll have a direct dependency on the canary there, which in turn has a direct dependency on Logback, so you're indeed stuck with a Logback dependency). WRT reconfiguration, IIRC Logback simply sticks with the previous configuration if the new configuration is faulty. Which may or may not be what you want, depending on the exact reasons why you consider a broken log configuration fatal. I tend to construct my log configuration by putting a fallback Logback configuration into the classpath, and load that first. I can test that configuration and be confident that the software will always start with a minimum viable log configuration. This happens during start-up, i.e. in main() or in the webapp's initialization hooks. I want logging to be initialized as early as possible, which sort-of automatically concentrates the dependency in one place where it is easily managed.

slf4j backend configuration errors are not fatal ------------------------------------------------

Key: SLF4J-433 URL: https://jira.qos.ch/browse/SLF4J-433 Project: SLF4J Issue Type: Improvement Reporter: Thorbjørn Ravn Andersen Assignee: SLF4J developers list

I know that a great deal of care has been put into making slf4j invisible to the application doing the logging.  This includes configuration errors being transparent and all. We consider logging framework configuration errors fatal, and would like a mechanism that can tell the main application that the logging framework is broken so it can do an emergency shutdown.      Our usecase is at application start up (first logging statement) but the generic case would probably be after each (re)configuration. As we by default cannot specify this through the configuration file, this probably needs to be triggered by a system property.  I'd really prefer a solution which does not "know in application code" that the slf4j backend is logback.  

-- This message was sent by Atlassian JIRA (v7.3.1#73012)