[slf4j-user] "Fail loudly" for NOP implementation
Joachim Durchholz
jo at durchholz.org
Wed Sep 9 12:01:21 CEST 2015
Am 09.09.2015 um 00:54 schrieb Steven Schlansker:
> I have noticed a pattern in Java applications I develop - generally, we like to use
> logback for our deployments, and slf4j-simple during tests.
>
> It is very easy to accidentally misconfigure your Maven POM and end up getting the
> classic "No StaticLoggerBinder found, defaulting to NOP" message, and then not get
> any output at all.
>
> Would people enjoy having the option to subscribe to the "fail early and fail loud"
> school of thought,
A good strategy in general.
> and have a way to configure the LoggerFactory to fail fatally
> rather than default to NOP?
There are use cases where logging is merely nice to have, so the logger
doesn't know whether it should fail in the first place. It's a
per-application decision, so the decision should be made in the app, or
maybe in the deployment configuration.
Is it possible remove the NOP logger from the build? That should end in
a ClassNotFound hard-fail and cover use cases like yours where logging
isn't merely nice-to-have but a reason to scream at the DevOps team.
> I am imagining something very simple, essentially
> changing LoggerFactory#bind to inspect a system property or environment variable,
> and if it is set cause binding to fail rather than NOP.
Now you need to worry about the environment variable's settting getting
accidentally pushed to production.
That's going to reduce the problem, but not solve it; I suspect it's not
worth the complication for everybody (since now everybody needs to check
that this environment variable is unset).
It's something of a last resort, and even then I'd be unhappy to have to
worry about that. (Slapping on another configuration option is what
makes integration hard, and it's a rampant problem in the Java world;
I'd want to avoid that as much as possible.)
More information about the slf4j-user
mailing list