[slf4j-user] Fail Silently on NOP implementation

[Ceki Gulcu]

In short, I agree 100% with Marshall's reasoning.

On 4/28/2016 15:35, Marshall Pierce wrote:

 > The job of slf4j-api is just to be the developer-side interface to
 > logging. It purposely delegates the decision of what to do with those
 > logs to the end user. I think it is a mistake to include policy
 > mechanisms like these into the API.
 >
 > If you’re writing a library, don’t include a binding. If you’re
 > writing a tool, select a binding. It is an error to not include a
 > binding, and that’s why it prints to stderr. If you’re writing a tool
 > and you want silence, use nop. If you’re not writing a tool, it’s not
 > your decision.

Yes.

 > Regarding slf4j-silent / slf4j-strict: This is just another “policy
 > via classpath” mechanism. If you want to control the output of
 > calls made via slf4j-api, we already have a mechanism for this. What
 > happens when both are on the classpath? As a new user to SLF4J, would
 > you really enjoy learning how to use dependency excludes as a
 > debugging tool during your “why won’t my logging show up”
 > journey rather than having a clear error message that informs you that
 > you’re doing it wrong, and pointing you towards the URL with more
 > info? This complicates logging, and the debugging thereof, without a
 > clear gain.

Yes. Well put.

 > The fundamental issue is that you’re trying to use the same artifact
 > as both a library and an end-user tool (which I’ll define as “a
 > thing with a main method or equivalent”). This is an antipattern
 > because there are conflicting goals for libraries and tools, as you’ve
 > correctly identified. If your users will consume your code in two
 > different ways, then it is sensible to have two different artifacts.

Yes, having two artifacts seems reasonable to me. However, it may be 
asking too much of someone two create two artifacts just to tame 
logging. In any case, SLF4J implicitly assumes that there is a clear 
distinction between code packaged as a library and code packaged as an 
application.

--
Ceki