Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No-op logger is not a sane default #387

Open
sesm opened this issue Jan 21, 2024 · 3 comments
Open

No-op logger is not a sane default #387

sesm opened this issue Jan 21, 2024 · 3 comments

Comments

@sesm
Copy link

sesm commented Jan 21, 2024

If no SLF4J providers are found, SLF4J defaults to no-op logger, which results in all logs, including errors and exceptions being hidden.

IMO this is not a sane default, a better default would be logging exceptions, errors and warning to stdout. stdout is perfectly fine for development and became a common practice for Docker containers in production.

The codebase already has SimpleLogger that does this, but when I tried to reference it in slf4j.LoggerFactory it introduced a circular dependency. Maybe it makes sense to copy SimpleLogger to base package, remove all extra code for configurability/etc, call it FallbackStdoutLogger and use it by default?

@asolntsev
Copy link

@ceki Upvote. "No-logger" default is terrible. Let's change the default to "slf4j-simple".

My case: I am an author of several open-source libraries. I want to use slf4j in my library.
There is many users who don't care about logging. They just want to run my library. But they see this annoying error message:

SLF4J(W): No SLF4J providers were found.
SLF4J(W): Defaulting to no-operation (NOP) logger implementation
SLF4J(W): See https://www.slf4j.org/codes.html#noProviders for further details.

And they don't follow this link and don't want to waste mental resources to investigate how to fix this yet another annoying issue.

Let's log to console by default!
And who wants, can configure any custom logging framework.

@ceki
Copy link
Member

ceki commented Nov 6, 2024

@asolntsev After some thinking, I think your proposal could be made to work.

However, while some users might appreciate to see logs appearing without effort, some other users might be discomforted to see their previously logless application spewing tons of logs. Anyway, it is a relatively important change that would need some maturing.

I very much appreciate your proposal and thank you in the mean time.

@asolntsev
Copy link

asolntsev commented Nov 6, 2024

@ceki I understand you concern, and I have a suggestion to solve it.
Let's have another module in addition to slf4j-api and slf4j-simple: say, slf4j-fallback.
My library will depend on this module.
And this slf4j-fallback module will print logs to console by default.

UPD
Or even simpler: let's slf4j-simple behave like this (instead of introducing new module):

  • if only slf4j-simple is present in classpath, it's used.
  • if any other logging framework is also present in classpath, it's used (without any warnings, just ignoring presence of slf4j-simple).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants