Continously getting the "following set of loggers may have been accessed" logback

Question

I am using logback for logging in my applications and I am continuously getting the following warning everyime i run the application. When I run the unit tests, its getting printed for every class!

SLF4J: The following set of substitute loggers may have been accessed
SLF4J: during the initialization phase. Logging calls during this
SLF4J: phase were not honored. However, subsequent logging calls to these
SLF4J: loggers will work as normally expected.
SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger
SLF4J: com.kohls.kube.service.sdk.logging.CustomAppender
SLF4J: com.kohls.kube.service.sdk.logging.appender.mqtt.messaging.ClientMqttImpl
SLF4J: com.kohls.service.sdk.messaging.TCPMessager
SLF4J: com.kohls.service.sdk.logging.appender.mqtt.MQTTAppender
SLF4J: com.kohls.service.sdk.messaging.EdgeNodeMessager
SLF4J: com.kohls.service.sdk.messaging.SubscriptionTask

I have configured the logback to look for the config file in a certain location and below is how the log factory class looks like.

public class LoggerFactory {

static {
    System.setProperty("logback.configurationFile", System.getProperty("user.dir") + "\\" + "logbackConfig.xml");
}

private LoggerFactory() {

}

public static Logger getLogger(Class className) {
    return org.slf4j.LoggerFactory.getLogger(className);
}

}

Then I am retrieving the loggers like,

private static Logger logger = LoggerFactory.getLogger(ClassName);

My config XML file looks like below.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>

    <statusListener class="ch.qos.logback.core.status.NopStatusListener"/>

    <!-- Send debug messages to System.out -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <!-- By default, encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
            </pattern>
        </encoder>
    </appender>

    <appender name="MQTT" class="com.kohls.service.sdk.logging.appender.mqtt.MQTTAppender">
        <!-- By default, encoders are assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
        <encoder>
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
            </pattern>
        </encoder>
        <url>tcp://localhost:1883</url>
        <clientId>MqttAppender</clientId>
        <topic>log</topic>
    </appender>

    <!-- Send debug messages to a file at "c:/jcg.log" -->
    <appender name="FILE"
              class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>./UpdaterLog.log</file>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <Pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{0} - %msg%n</Pattern>
        </encoder>

        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <FileNamePattern>./archive.%i.log.zip</FileNamePattern>
            <MinIndex>1</MinIndex>
            <MaxIndex>10</MaxIndex>
        </rollingPolicy>

        <triggeringPolicy
                class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <MaxFileSize>2MB</MaxFileSize>
        </triggeringPolicy>
    </appender>

    <!-- By default, the level of the root level is set to DEBUG -->
    <root level="DEBUG">
        <!--<appender-ref ref="MQTT"/>-->
        <!--<appender-ref ref="FILE"/>-->
        <appender-ref ref="STDOUT"/>
    </root>

</configuration>

I have made sure that there are no other XMLs anywhere. Only this one is there. What am I doing wrong here? Why am I continuously getting this warning? Please advice.

Answer 1

You are not doing anything wrong. Your application is already multi-threaded at the point where the first LoggerFactory.getLogger call is made. Earlier versions of SLF4J (1.7.14 and earlier) emit the above warning message. More recent versions of SLF4J (1.7.15 and later) will capture log messages made during SLF4J initialization phase and will replay them just after.

Updating to more recent version of SLF4J is likely to solve the issue. Alternatively, you can initialize SLF4J earlier on in your application start up.