You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The inclusion of "org.slf4j" % "slf4j-simple" % "1.6.4" as a dependency causes problems with multiple StaticLoggerBinder implementation warnings:
SLF4J: Class path contains multiple SLF4J bindings.
Due to the inability to specify which SL4J implementation to use, this means that the first loaded JAR implementation of StaticLoggerBinder wins. In environments where you can't easily control the classpath order (e.g. the universal packaging format output by SBT), this is a problem.
Including the sl4j-api dependency alone will be enough and allow people using this lib to choose their own logging framework! :)
The text was updated successfully, but these errors were encountered:
Agreed. I'm new-ish to Java/Scala logging, but I get the impression that it's bad form to specify a concrete logging implementation in a library meant for public use — kind of like logging to stdout: it prevents downstream users from being able to sanely handle logs emanating from your library.
For anyone else arriving here from Google, replace (in your build.sbt's libraryDependencies):
The inclusion of
"org.slf4j" % "slf4j-simple" % "1.6.4"
as a dependency causes problems with multipleStaticLoggerBinder
implementation warnings:SLF4J: Class path contains multiple SLF4J bindings.
Due to the inability to specify which SL4J implementation to use, this means that the first loaded JAR implementation of StaticLoggerBinder wins. In environments where you can't easily control the classpath order (e.g. the universal packaging format output by SBT), this is a problem.
Including the
sl4j-api
dependency alone will be enough and allow people using this lib to choose their own logging framework! :)The text was updated successfully, but these errors were encountered: