SLF4J Logging Warnings

[reardonj]

When I trying running a simple http4s client app with Typelevel Toolkit, I get warnings about SL4FJ at startup:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

I can get rid of them with //> using dep ch.qos.logback:logback-classic:1.5.3
Maybe the toolkit should include a default logging implementation out of the box? I have no interest in remembering to configure logging when I'm trying to do a quick script.

[TonioGela]

I think this issue sits on the edge between being an http4s issue and being a toolkit issue.

That said, IMHO there's no simple solution: adding logback is absolutely not the right thing to do, as it won't work on scala native and scala.js.
On the other hand adding something like log4cats no-op will mute every possible log stament and code that is copy pasted from bigger codebases will work but not log any statement.

Forcing users to decide and pick their own logging framework is probably still the best thing to do.
Despite the fact I appreciate the "all-in-one" nature of the toolkit, I think this is one of the cases where keeping it general has more value than keep it EVEN MORE practical.

[armanbilge]

adding logback is absolutely not the right thing to do, as it won't work on scala native and scala.js.

I wouldn't go so far as to say that. We could add it for JVM only.

I think this issue sits on the edge between being an http4s issue

This is literally an http4s issue :)

• ember server: don't include log4cats-slf4j  http4s/http4s#6721

[TonioGela]

I wouldn't go so far as to say that. We could add it for JVM only.

Yay, it was probably too bold, sorry

[reardonj]

Not having SLF4J in the toolkit dependency tree would be even better. Is http4s 0.23.x stuck with it? If I'm reading the issue right, it's already removed from 1.0?

Forcing users to decide and pick their own logging framework is probably still the best thing to do.

But I don't want to be forced to pick a logging framework for the web scrapper I'm quickly typing up and going to use 3 times! IMO, the value of having a toolkit is greatest for people writing fairly small scripts that aren't going to see extensive use. Having to puzzle out a cryptic warning from a non-Typelevel dependency that is somehow the first thing my http4s script prints out is not great ergonomics for that use case.

[armanbilge]

Not having SLF4J in the toolkit dependency tree would be even better

I agree.

Is http4s 0.23.x stuck with it? If I'm reading the issue right, it's already removed from 1.0?

Yes, stuck in 0.23, removed in 1.0.

Having to puzzle out a cryptic warning from a non-Typelevel dependency that is somehow the first thing my http4s script prints out is not great ergonomics for that use case.

😢 yeah this sucks

[reardonj]

That is really unfortunate. So there is no way out until 1.0. Adding an slf4j logger to the toolkit would kind of work, until the user does want to pick a logger, because slf4j also complains about having more than one.