[slf4j-user] "Fail loudly" for NOP implementation

[Steven Schlansker]

On Sep 9, 2015, at 3:01 AM, Joachim Durchholz <jo at durchholz.org> wrote:

> 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.

Unfortunately the NOPLoggerFactory is baked into slf4j-api as it is statically referenced as the fallback factory, for this exact purpose.
Otherwise that would be an excellent approach, I would use a Maven <exclude> and be done with it.

I agree this is a per-applicaiton decision, hence my suggestion of a configuration parameter.

> 
>> 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.

We actually explicitly want this in production.  I would much rather have an application crash on launch and
fail a deployment, rather than run with no logging output and "succeeding"!

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

I get where you are coming from, but I can't see this proposal being adopted as the default.  As much as I want it, it would be a breaking change,
and probably a total non-starter.  Given that, I don't see any ways to do it other than such a configuration option?  Did you have another suggestion?