[slf4j-user] Fail Silently on NOP implementation

[Steven Schlansker]

> On Apr 27, 2016, at 1:00 AM, Phillip Lord <phillip.lord at russet.org.uk> wrote:
> 
> 
> 
> The currently implementation of SLF4J prints a message on usage of the
> NOP implementation. This is not very friendly at all, as it means that
> if any dependency of my project includes a a dependency on SLF4J, I
> suddenly get an error message whether I wish it or not.

Wow, you run Java apps without wanting slf4j logging?  Who even does that
nowadays? ;)

> 
> It seems poor to me that I should have to add a dependency to slf4j-nop
> in my project -- I now have to check everytime I update my dependencies
> to see whether this is still necessary, so it's an ongoing cost, in
> addition to the initial cost of finding out what this error message is
> about in the first place.
> 
> I would like to suggest that this message be suppressed unless
> explicitly asked for; users of slf4j could them choose to be warned when
> they wanted. They could also ask for a fail early implementation as was
> requested earlier on this mailing list.
> 
> http://mailman.qos.ch/pipermail/slf4j-user/2015-September/001478.html
> 
> This could be implemented in a number of ways -- you could make a
> slf4j-api-with-noisy dependency, you could look for an environment
> variable, or a system property. Users who need the warning would get it,
> and end-users who are not using slf4j explicitly would be untroubled by
> its presence,

I suspect that changing the default behavior is out of the question, at
least until a 2.x.x major release.  Additionally, some of the pushback
I received with the earlier approach was about the difficulty of managing
and lack of visibility associated with system properties.

So how about this:

slf4j-api retains current behavior.  Log if nop / duplicate implementation.

-> Introduce a "slf4j-silent" jar which modifies the slf4j logger binding
   process to be silent

-> Introduce a "slf4j-strict" jar which modifies the slf4j logger binding
   process to fail explosively on any trivial misconfiguration

This probably only requires a single hook inside of the LoggerFactory,
same way you hook StaticLoggerBinder there could be a
StaticLoggerBindingConfiguration which is provided by one of these jars
(or silently absent, in the "default" case)

Then, assuming the end user has good control of their build process, they
can elect to introduce one or the other (Personally, I would include
"slf4j-strict" in our default Maven parent POM globally)

The biggest downside is you wanted a "no additional configuration necessary"
solution, but I don't think that is possible -- the default case is already
defined and likely won't change.

Would this approach be welcome by the developers?  Would it solve your
problem satisfactorily, even though it's not 100% what you wanted?

Best,
Steven

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20160427/99fe02aa/attachment.sig>