[slf4j-user] Fail Silently on NOP implementation

[Joachim Durchholz]

Am 29.04.2016 um 12:26 schrieb Ceki Gulcu:
> SLF4J's approach of binding with an implementation by directly
> invoking the org.slf4j.impl.StaticLoggerBinder.getSingleton() method
> from within LoggerFactory is primitive and very unsophisticated. Other
> approaches to this problem, e.g. OSGi, address many of the
> shortcomings of the direct invocation approach. However, OSGi is very
> hard to master and only a small minority of developers understand
> it. In contrast, the SLF4J approach can be understood by most
> programmers on their first day of programming in Java.

Point.

> SLF4J's static binding approach is a direct reaction to the dynamic
> binding approach (via classloader inspection) as adopted by Jakarta
> Common Logging. The classloader approach is more convenient in many
> cases but may become extremely complicated to debug when things go
> wrong, see [1].

Point, but it's worse: If classpath inspection fails, you need to log 
that somewhere. But the logger doesn't work. Catch-22.

Considering the options, I think SLF4J is right on spot with that.
Also, making the loggers dynamically configurable or anything just 
complicates things, adds more failure modes that might need to be logged.
I really think that Phillip hasn't seen the use cases for which SLF4J 
was built, and hence has no idea why libraries and applications are such 
different beasts and how there might be needs that diverge from his.

> Jigsaw (new in Java 9) purportedly provides a solution to the jar hell
> problem.

Well, it's the question whether you want to allow another configuration 
mechanism than jar inclusion in the classpath.

 > I wonder how SLF4J could be modified to cater for Jigsaw
> modules.

It might be a good idea to separate the static-binding aspects out into 
separate libraries. I.e. slf4j-simple.jar retains just the 
StaticLoggerBinder, and there's a Maven dependency on the new 
slf4j-simple-implementation.jar that has all the rest.

That way, you could write a DynamicLoggerBinder that can switch between 
loggers.

Maybe my imagination is too limited, but the only use case I can come up 
with for this kind of stuff is testing. It would be nice to test all 
backends without having to fire up a separate JVM or classloader for 
each test.
In general, I don't want the logging layer to be dynamically replacable. 
There be dragons there - logging is for code that needs to be monitored, 
and it needs to be primitive so it can be failsafe.

Just my 3c.
Jo