On Sep 9, 2015, at 3:01 AM, Joachim Durchholz <[email protected]> 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? _______________________________________________ slf4j-user mailing list [email protected] http://mailman.qos.ch/mailman/listinfo/slf4j-user
