Howard is saying so long, commons-logging, hello SLF4J.
I had to giggle a little bit here. When commons-logging came along to abstract your logger which abstracts your println (I know…. you CAN write an appender that sends you SMS messages and launches rockets) I thought “wow”.
Only the J2EE community would architect twelve levels of abstraction to handle a filtered logging system.
After years of use we realise that the last level of abstraction doesn’t do anything for you… but instead of just ignoring it, we have a new one!
The non-Apache follow on to commons-logging is SLF4J. It does things right: Logger, not Log. Better yet, Logger is an interface (it’s a class in Log4J) which makes my EasyMock-addled brain quite happy. Finally, SLF4J takes a very simple, very sane approach: you combine the API JAR with one of several implementation JARs. That’s it … no class loader magic, no dynamic binding. This is an ideal solution for those same 99.99999% of applications out there.
Maybe someone could write an abstraction layer on top of commoons-logging and SLF4J…. you know, so you could switch between then without changing the interface.
February 7th, 2008 at 4:57 pm
SLF4J does already come with two abstractions for interacting with commons logging– one jar that emulates commons logging and can completely replace the commons-logging jar and another one that sends it’s logging messages to commons logging as it’s target logging system.
October 1st, 2008 at 12:46 pm
I prefer to do all my logging to paper.
November 14th, 2008 at 3:53 pm
I prefer reading intelligent discussions.