Details
-
Bug
-
Resolution: Unresolved
-
Trivial
-
None
-
1.7.x
-
Tomcat 8
-
enhancement
-
P4
Description
We have a situation where SLF4J is being used in a tomcat container level valve, as well as inside the web applications.
So specifically we have:
CATALINA_HOME/lib/log4j-slf4j-impl-.jar - used for container level valves. Unfortunately it must be placed here, because the valves don't come packaged the jar, and log4j2 is being used for the container level logs.
CATALINA_BASE/webapps/<some_webapp>/WEB-INF/lib/log4j-slf4j-impl-<>.jar - many web developers use slf4j inside their web applications, with log4j2 for their app level logs, which may or may not be the same version as in CATALINA_HOME.
When starting tomcat an error from standard err shows up saying there are multiple slf4j bindings in the classpath. The problem here is that the slf4j-api.jar used for the container can't be hidden from the web applications, but tomcat (and many other J2EE containers) loads the jars inside the webapp before loading the container level jars. So while is true that there are multiple slf4j bindings on the classpath, the correct one will be evaluated in this case, and there is no issue. However if for some reason the developer of the webapp had multiple slf4j jars inside their webapp, it would be arbitrary which one loads, and thus the warning would be useful.
A possible solution could be to allow a system property, context param, or something else, that identifies the app as a tomcat or other servlet based webapp, and if it is, only warn the user of multiple slf4j bindings if the bindings are in the webapp's WEB-INF/lib or WEB-INF/classes dirs.
Also, I would be happy to make the changes, provided the community agrees with the solution. It looks straight forward to place them in: https://github.com/qos-ch/slf4j/blob/master/slf4j-api/src/main/java/org/slf4j/LoggerFactory.java#L292