Getting rid of internal SLF4J messages

[dglugla]

How can I get rid of the internal SLF4J messages (info, warnings, errors)?

The case is that I already limited dependencies to the bare minimum and configured the SLF4J implementation (Log4j2), but I'm still getting some of the SLF4J messages printed directly to the console.
I'm not able to filter them out using any of the log4j appender configuration, as I assume they're being printed directly to the system console output.

I have a utility app which should print only the JSON output to the console, which is then processed by Jenkins. But the SLF4J adds its own message:

SLF4J(E): A service provider failed to instantiate:
org.slf4j.spi.SLF4JServiceProvider: ch.qos.logback.classic.spi.LogbackServiceProvider Unable to get public no-arg constructor

or

SLF4J(W): Class path contains multiple SLF4J providers.
SLF4J(W): Found provider [org.apache.logging.slf4j.SLF4JServiceProvider@3af49f1c]
SLF4J(W): Found provider [ch.qos.logback.classic.spi.LogbackServiceProvider@19469ea2]
SLF4J(W): See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J(I): Actual provider is of type [org.apache.logging.slf4j.SLF4JServiceProvider@3af49f1c]

and fails the build due to assertion checks.

[ppkarwasz]

You should clean up your dependency stack from all SLF4J implementations, except the one you are using. If you use Maven, you can do it with
an enforcer rule like this one and fix all the errors using exclusions.

Unfortunately there is no Maven Enforcer rule counts the number of service implementations on your stack, so you need to ban them explicitly. If you use o.a.l.l:log4j-slf4j2-impl, you should ban:

• c.q:logback-classic,
• o.a.l.l:log4j-slf4j-impl,
• o.s:slf4j-nop,
• o.s:slf4j-simple,
• o.s:slf4j-jdk14,
• o.s:slf4j-reload4j.

Note: If you didn't add any of these dependencies explicitly to your runtime, you should check which dependency leaks them and report the issue to the appropriate project. A lot of libraries leak SLF4J implementations as required runtime dependencies.

[dglugla]

Thanks @ppkarwasz!

While that solves a problem of the messages printed directly to the System.err (or .out) by SLF4J, it creates another with missing runtime dependencies.
One of the excluded packages (namely the c.q:logback-classic) is referenced by dropwizard, so now it fails with:

java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: ch/qos/logback/classic/Level

And yes - I'm aware that it's a dropwizard issue apparently existing for few years now, but since it hasn't been solved since then, I'm looking for a workaround.

[ppkarwasz]

As workaround, you can specify the slf4j.provider Java system property, which is available since SLF4J 2.0.9:

-Dslf4j.provider=org.apache.logging.slf4j.SLF4JServiceProvider

See the FAQ entry for more details.

Note also that SLF4J internal warnings and errors are printed to System.err. If your application uses System.out, you should be able to separate the two streams.

[dglugla]

Thanks @ppkarwasz - we'll eventually need to ignore System.err stream.
Even though I followed all the recommended steps in project's configuration, I end up either having SLF4J infos/warnings/errors logged directly to the console, or runtime exception.
I don't want to precisely exclude dependencies of the sub-...-dependencies, as it will be hard to maintain and diagnose later.