I could be wrong on this, but something to take into account with slf4j... I have seen a few projects that logged a custom MessageObject which different appenders do differing things with. E.g. a file appender will toString() it, but a custom DB appender might use the object properties and a prepared statement. I believe slf4j will call the toString() before it reachers your appenders so it breaks this functionality.
Disclaimer: I really may be wrong, but I certainly saw this behavior and reverted to commons logging on those projects, and it could be that slf4j now respects the original method signatures are (e.g.) log.info(Object) and not log.info(String) On Fri, Oct 2, 2009 at 9:49 AM, Steve Loughran <[email protected]> wrote: > Patrick Hunt wrote: >> >> I was watching this recently, it's very interesting: >> http://www.java-tv.com/2009/09/24/slf4j-and-logback-projects/ >> slf4j has some very nice properties, not the least that it solves some >> problems like simplifying integration of apps that use different logging >> systems. >> >> I had noticed that Avro uses slf4j, and that Hadoop in general has it as >> part of the ivy config (although the code is still log4j based). Is the >> intent to move all of Hadoop to slf4j over time? >> >> Patrick > > SLF4J is there because jetty uses it. If it had stayed with commons-logging > it would be that much easier to run different logging back ends, as it is I > have to have two different bridge libraries to integrate hadoop logging with > where the data goes in my clusters. >
