Why a Logging Framework Should Not Log

Archive.org cached version: https://web.archive.org/web/20160505153552/http://www.russet...

This is a well understood problem and I think the design pattern SLF4J uses has become quite popular.

The ability to allow consumers to bind at runtime the implementation they want by providing an api jar is kind of a neat idea.

The thing I dislike the most is when libraries force me to use their logging runtime. If they need it just for tests they should add the 'test' scope and just use the 'api' jar as a 'compile' dependency.

No, this guy is 100% wrong. The distinction is absolutely clear. If someone else is expected to build on top of a framework he provides then he is building a library, and it would be inappropriate to tie future consumers to a back-end. This is relatively simple to fix - you mark his library as a dependency and add an additional for slf4j-nop to that dependency, but it's not the right way to do this. Those messages aren't meant for him, they're meant for future consumers, and now after including his library they have to dig through and figure out why SLF4J suddenly broke.

I can't find exactly what this Tawny-OWL thing is (his link is broken), but it sounds like it might have some kind of interpreter application provided. If he is offering a finished application within the same build unit as his UI library, this is the "big ball of mud" architecture. The fix is to break his application out into a separate build unit that depends on his library. The application can then include slf4j-nop without messing up SLF4J for all his library's consumers. Maven Reactor can automatically build his dependencies when his main application builds, if desired.

The thing about having to deal with 2 different logging frameworks is exactly what SLF4J is meant to fix. SLF4J lets you route the messages from multiple sources to a single sink/backend defined by the final consumer application. Yeah, it sucks to deal with multiple logging frameworks, but that's simply how it is and you don't help anything by having a whinge about it. You include the routing/bridge modules (JUL-to-SLF4J, Commons-to-SLF4J, etc) in the final-consumer application and call it a day. If you don't want to do that, find some other dependency that doesn't use those logger frameworks.

Whoa. The author recommends including slf4j-nop as an explicit dependency of libraries?! This means that when a developer writes an application and forgets to include an slf4j backend, instead of getting a warning that no backend is configured, that developer will get absolutely no output. This is really bad advice.

My framework is built in Clojure. The interpreter is always there. Think of it like a statistics library with R.

The idea of a "main application" is itself not a clear one. There are a set of functions you can use. Whether you choose to launch directly over the library or import it is a matter of convenience.