Logback is used directly

Currently both logback and slf4j are required dependencies in Dropwizard. And since you can only have one implementation of slf4j in your class path it’s not possible to use slf4j-log4j12, for example.

As far as I understand it’s suppose to be up to the developer as to what implementation of slf4j to use. I suggest that logback is not used directly but only through slf4j and that logback-classic, logback-core and logback-parent are added as runtime dependencies. This would make it possible to exclude then and use a different implementation.

From the slf4j manual:

Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J’s purpose. When you come across an embedded component declaring a compile-time dependency on any SLF4J binding, please take the time to contact the authors of said component/library and kindly ask them to mend their ways.

My case:

If I chose to include both logback and slf4j-log4j12 the following messages are shown:

SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/.../.m2/repository/org/slf4j/slf4j-log4j12/1.7.13/slf4j-log4j12-1.7.13.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/.../.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]

Exception in thread "main" java.lang.IllegalStateException: Unable to acquire the logger context
    at io.dropwizard.logging.LoggingUtil.getLoggerContext(LoggingUtil.java:46)
    at io.dropwizard.logging.BootstrapLogging.bootstrap(BootstrapLogging.java:45)
    at io.dropwizard.logging.BootstrapLogging.bootstrap(BootstrapLogging.java:34)
    at io.dropwizard.Application.<init>(Application.java:24)
    ...

If I chose to include only slf4j-log4j12 and exclude logback the following messages are shown:

Exception in thread "main" java.lang.NoClassDefFoundError: ch/qos/logback/core/filter/Filter
    at io.dropwizard.Application.<init>(Application.java:24)
    ...
Caused by: java.lang.ClassNotFoundException: ch.qos.logback.core.filter.Filter
    at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 4 more

As you can see neither approach works out.

[jhalterman]

@joschi I think this issue was closed a bit too soon.

As @t-oydna points out and as the slf4j manual describes, having an explicit dependency on logback or anything else can and will cause conflicts with other things on the classpath. I know of one project, where I had championed Dropwizard, that was forced to abandon it entirely because of this. In that project, Spark, which like Dropwizard also uses slf4j but instead opts for a log4j bridge, sets up the classpath and loads the log4j bridge before Dropwizard can attempt to load logback. Obviously slf4j complains, but since Dropwizard uses logback APIs directly, there is no way to make logging work for both Spark and Dropwizard.

Regarding this:

you can exclude the logging framework from other libraries and replace them with the appropriate SLF4J legacy bridge

In the case of spark, when used via spark-submit, there is no way to exclude log4j.

So two thoughts:

• There is absolutely no point in Dropwizard even using slf4j if it requires, through a dependency, usage of Logback. As the slf4j manual states, this negates the purpose of slf4j.
• The logback dependency, basically, makes Dropwizard’s ability to log incompatible with any other technology that is similarly opinionated about logging and runs in the same process/classloader, like Spark.

Why limit potential adoption of Dropwizard and force users to abandon it over logging?

[arteam]

Since Dropwizard 1.2.0 it’s now possible run an app without Logback (#1900 and #2112)