Im not sure how many of you are familiar with this, but running the same application in two different environments is causing my spring boot app to load its logging dependencies in a different order. Im running with logback-classic-1.1.7 as well as slfj4j-log4j12-1.7.13.
Now, I know now that logback has slfj imbedded in it (at least, now I do) and it normally would show a multiple binding warning, and then it would proceed. The app would start.
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/root/dev2/target/lib/logback-classic-
1.1.7.jar! /org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/root/dev2/target/lib/
slf4j/slf4j-jdk14/1.5.3/slf4j-jdk14 1.5.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Actual binding is of type
[ch.qos.logback.classic.util.ContextSelectorStaticBinder]
//Spring then starts the app successfully here.
I've read that sometimes when slf4j finds multiple bindings it would sometimes select one at random. I have removed the other unnecessary dependency, and that has solved my problem. Im more interested in WHY the same app would load the wrong logger by running on a different server with the same linux version. Running on another environment, the result when I try to start it is:
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/root/dev3/target/lib/
slf4j/slf4j-jdk14/1.5.3/slf4j-jdk14 1.5.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/root/dev3/target/lib/logback-classic-
1.1.7.jar! /org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Actual binding is of type
[org.slf4j.impl.Log4jLoggerFactory]
Exception is in thread "main" java.lang.IllegalArgumentException: LoggerFactory
is not a Logback LoggerContext but Logback is on the classpath.
Either remove Logback or the competing
implemenataion (class org.slf4j.iml.Log4jLoggerFactory...
//app then fails to start
In this environment, it loads the two competing loggers in the opposite order and then the app fails to start. Does anyone know more about the behavior Spring's loading of dependencies and why it would load them in different orders in different environments? This caused this error to go unnoticed for some time. Both environments have the same linux version.
Thanks in advance
