Does Log4j go for Slf4j?

Question

Log4j seems to have some problems loading classes (in other words), and it seems to me that the tendency is to go from log4j to slf4j. (Hibernate stopped using the former in favor of the latter)

• It's true?
• What are the main issues in log4j that slf4j resolves?
• Is slf4j the last word, or is there even a better “next log4j next” industry standard?

Update:

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

You seem to have stumbled upon a major issue with log4j (and the Apache Commons Logging Library), namely that they are ridiculously hard to find and interact with the correct classloaders as they need to be used. There is a very tight explanation, complete with examples, here; The report that one of the main driving forces for the new SLF4J logging system was to completely eliminate these problems. may want to change it and see your life is getting easier.

• More log4j download problems: http://articles.qos.ch/classloader.html

Answer 1

Slf4j is really just a logging facade. However, Log4j should be replaced by Logback from the same authors.

Update : if you want to learn about another advantage of Slf4j, then the fact that the following (ugly) constructs are no longer needed to avoid an unnecessary call toString() :

 if (logger.isDebugEnabled()) { logger.debug("Message: " + bigObject + ", " + anotherBigObject); } 

Instead, you can use parameterized messages:

 logger.debug("Message: {}, {}", bigObject, anotherBigObject); 

Also see What is the fastest (non) logging method?

Answer 2

Slf4J is not an alternative to Log4j, but rather provides Facade for logging, so you can connect your own logging system. This is mostly useful for libraries. from slf4j.org:

A simple logical facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frames, for example. java.util.logging, log4j and logback, which allows the user to attach the required frame log during deployment.

To answer your question: now Slf4j is accepted by frameworks, but in your projects you can continue to use Log4J (or any other)

Answer 3

First: an important point: Slf4j is a frontend logging (API) that can be used below most major loggin systems: for example, log4j or java.util.logging. Therefore, it is better to compare sfl4j with commons-logging .

About Log4j status, quotes from java Registration Status (a year ago)

One thing that I did not understand is that developing log4j is almost dead. It is currently in version 1.2, and plans for version 1.3 have been canceled in favor of developing log4j 2.0. However, it seems 2.0 is not in active development. It is worth noting that Ceki Gülcü, the original founder of the log4j project, switched to slf4j (see below).

Answer 4

Looking at the slf4j page , it looks like it will replace log4j - it will simply allow you to use the same basic logging structure (e.g. log4j) for the entire application, allowing libraries to automatically connect to them.

It is more like replacing Apocal Commons Logging than log4j.

Answer 5

SLF4J has, in my opinion, a huge advantage in that you can unify the logging of all the libraries that you use through the bridges that it provides. This does not allow any of the other registration frameworks. This allows projects to seamlessly migrate to SLF4J and ignore the choice of protocol frameworks that were made by dependencies.

Answer 6

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

• Slf4j cannot specify a user configuration file, but forces the user to use default (log4j.properties or log4j.xml) on one of the many Java roots (each Jar has one root plus a JVM root and classes or bin). If two JAR files have this, it's hard to control which one is safe to use.
• Slf4j cannot support all levels of Log4j, such as fatal. When switching large code from Log4j to Slf4j, a tremendous effort is required to change the code (for example, the decision to reorder levels).
• Two key Jar files must be selected (log4j-over-slf4j.jar or slf4j-log4j12.jar). If the classpath will not work either. If you choose one random case, you lose unexpected functions (for example, log4j-over-slf4j.jar does not support several log files for the same classes, for example, one for the event log and one for the raw data log).