Comments on: Thoughts on Java logging and SLF4J

By: Nicolas Frankel

Nicolas Frankel — Mon, 23 Nov 2009 20:15:51 +0000

@kk Must have been lack of sleep or whatever: sorry about the mistake. This proves I should always make a prototype project synchronized with my post.

By: Nicolas Frankel

Nicolas Frankel — Mon, 23 Nov 2009 20:15:39 +0000

@Chris Wong Your point on the difference between wrappers and implementations is valid. Yet from a developer point of view, you call the API (which are all very similar) and magic happens. That was not the reason of the post, anyway. Choosing to redirect commons-logging directly to log4j is a personal choice. I prefer to manage the classpath than 2 parallel properties files.

By: kk

kk — Mon, 23 Nov 2009 17:59:14 +0000

“Remove from classpath: log4.jar Would cycle calls from SLF4J to Log4J and back again”

Slf4j doesn’t do any logging itself. slf4j-log4j *uses log4j* to do the actual logging and thus log4j.jar is required if using slf4j-log4j. See slf4j manual -> “Binding with a logging framework at deployment time”.

By: Chris Wong

Chris Wong — Mon, 23 Nov 2009 17:10:11 +0000

You should distinguish between logging wrappers (commons-logging, SLF4J) and logging implementations (log4j, JDK logging). There are reasons to choose wrappers over native implementations, and to choose between wrappers. Wrappers let you write logging code without worrying about concrete implementations: important if your code is meant to be used by third party apps that may have their own choice of logging implementation. Otherwise, they may be redundant. There are also newer implementations like logback that implement existing wrapper APIs. I generally configure both SLF4J and commons-logging to log through log4j so things don’t get scattered between different log files.

I blogged about this topic here:

http://chriswongdevblog.blogspot.com/2009/09/logging-should-i-wrap.html

By: Ben

Ben — Sun, 22 Nov 2009 22:37:44 +0000

Note that Logger.isDebugEnabled() doesn’t just avoid expensive String concatenation, but all expensive operations. So even with Slf4j you may still require such code blocks for cases where the log output requires an expensive operation, eg.

if (LOGGER.isDebugEnabled() {
LOGGER.debug(“Expensive result: {}”, someObject.getSomeExpensiveResult());
}

By: Nicolas Frankel

Nicolas Frankel — Sun, 22 Nov 2009 21:21:25 +0000

Hi Alexander,

You should remove commons-logging dependencies if 1. you want SLF4J to handle your log calls and 2. you provide jcl-over-slf4j.jar on the classpath. Hope I answered your question.

By: Ashitkin Alexander

Ashitkin Alexander — Sun, 22 Nov 2009 21:04:44 +0000

Hi Nicolas, thanks for your article. But after i’ve been read it i have a question – i should removedependencies from all projects relied on commons-logging?