Alex Rivera | Logout

Is Log4j being abandoned in favor of Slf4j?

Asked 2010-01-14T12:03:21.250
49

It seems that log4j has some class loading issues (among others) and it seems to me the trend is to move out of log4j toward slf4j. (Hibernate stopped using the first in favor of the latter)

  1. Is it true?
  2. What are the main issues in log4j that slf4j solves?
  3. Is slf4j the final word or is there even a better "the next next log4j" industry standard?

Update:

  • So this answer by delfuego confuses me, can you accept / object it?:

You appear to have stumbled upon the major problem with log4j (and the Apache Commons Logging library), namely that they have a ridiculously hard time discovering and interacting with the right classloaders as they're being used. There's a very dense explanation, complete with examples, here; the take-home message is that one of the primary driving forces for the new logging framework SLF4J was to eliminate these issues entirely. You might want to swap it in and see if your life is made any easier.

java log4j slf4j
Edit
Report

1 Answer

3

Slf4j is not a real logging facade. Slf4j does not support many features of its implementors. For short, I mention log4j examples below.

  • Slf4j cannot specify a user selected configuration file, but forces user to use default (log4j.properties or log4j.xml) at one of so many Java roots (each Jar has one root plus JVM root and classes or bin). If two JAR files have it, it is hard to control which one to use safely.
  • Slf4j cannot support all Log4j levels, such as 'fatal'. When switch big code from Log4j to Slf4j, huge code change effort is needed (e.g. deciding how to rearrange levels).
  • Two key Jar files (log4j-over-slf4j.jar or slf4j-log4j12.jar) must be chosen. If classpath both, won't work. If choose one randomly, lose unexpected features (e.g. log4j-over-slf4j.jar does not support multiple log files for same classes; e.g. one for events log and one for raw data log).
answered 2012-07-08T16:20:05.507

Your Answer