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
_______________________________________________
slf4j-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/slf4j-user
