scanPeriod attribute is required by logback-classic for auto-reload to work

Question

Is this a bug in logback classic or am I missing something? The documentation is pretty explicit about scanPeriod being an optional attribute:

By default, the configuration file will be scanned for changes once every minute.

However, given a logback.xml file like below:

<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="true" scan="true" >           
    <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5p %c{1}:%L - %m%n</pattern>
            <charset>utf8</charset>
        </encoder>
    </appender>
    <root level="WARN">
        <appender-ref ref="CONSOLE" />
    </root>
</configuration>

I get the following output from logback and scan does not work.

16:40:56,244 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
16:40:56,244 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
16:40:56,244 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/jbochenski/acme/acme-func-test/conf/logback.xml]
16:40:56,323 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
16:40:56,325 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CONSOLE]
16:40:56,331 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
16:40:56,354 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN
16:40:56,355 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [CONSOLE] to Logger[ROOT]
16:40:56,355 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
16:40:56,356 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@146ba0ac - Registering current configuration as safe fallback point

However if I just change the configuration to add scanPeriod attribute <configuration debug="true" scan="true" scanPeriod="1 minute"> it starts working:

16:43:44,584 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
16:43:44,585 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
16:43:44,585 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/jbochenski/acme/acme-func-test/conf/logback.xml]
16:43:44,686 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Will scan for changes in [file:/home/jbochenski/acme/acme-func-test/conf/logback.xml] 
16:43:44,686 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Setting ReconfigureOnChangeTask scanning period to 1 minutes
16:43:44,688 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
16:43:44,691 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [CONSOLE]
16:43:44,700 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
16:43:44,727 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to WARN
16:43:44,727 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [CONSOLE] to Logger[ROOT]
16:43:44,727 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
16:43:44,728 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@f6c48ac - Registering current configuration as safe fallback point

Using:

• logback-classic: 1.1.7
• slf4j: 1.7.13

Answer 1

UPDATE: See LOGBACK-1194

---

This indeed looks like a logback bug, and I recommend filing an issue in JIRA.

In 1.1.7, some refactoring was done that affects how the scanPeriod is handled. The changes included abandoning the scan option altogether when no scanPeriod is specified. I don't think that was intentional.