search

typelevel / toolkit

Quickstart your next app with the Typelevel Toolkit!
https://typelevel.org/toolkit
Apache License 2.0
94 stars 9 forks source link

SLF4J Logging Warnings #164

Open reardonj opened 4 months ago

reardonj commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 :)

TonioGela commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.