Log4j est-il abandonné au profit de Slf4j ?

Question

Il semble que log4j ait des problèmes de chargement des classes (entre autres) et il me semble que la tendance est de quitter log4j pour slf4j. (Hibernate a cessé d'utiliser le premier en faveur du second).

1. C'est vrai ?
2. Quels sont les principaux problèmes de log4j que slf4j résout ?
3. slf4j est-il le dernier mot ou existe-t-il un meilleur standard industriel "the next next log4j" ?

Mise à jour :

• Donc, ceci réponse par delfuego me trouble, pouvez-vous l'accepter / l'objecter? :

Vous semblez être tombé sur le problème majeur de log4j (et de la bibliothèque Apache Commons Logging), à savoir qu'ils ont un temps ridiculement temps de découvrir et d'interagir avec les avec les bons classloaders lorsqu'ils sont utilisés. Il y a une explication très dense explication, complète avec des exemples ici ; le message à retenir est que l'une des principales forces motrices du le nouveau cadre de journalisation SLF4J était de éliminer complètement ces problèmes. Vous Vous pourriez vouloir l'échanger et voir si votre vie est plus facile.

• Plus de problèmes de chargement de classe par log4j : http://articles.qos.ch/classloader.html

Answer 1

Slf4j n'est en effet qu'une façade de journalisation. Cependant, Log4j est destiné à être succédé par Logback de ces mêmes auteurs.

Mise à jour Si vous souhaitez connaître un autre avantage de Slf4j, il s'agit du fait que les constructions suivantes (hideuses) ne sont plus nécessaires pour éviter l'utilisation de l'outil de gestion de l'information. toString() inutilement appelé :

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

Vous pouvez à la place utiliser des messages paramétrés :

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

Voir aussi Quel est le moyen le plus rapide de (ne pas) enregistrer ?

Answer 2

Slf4J n'est pas une alternative à Log4j, mais fournit plutôt une solution de rechange à Log4j. Façade pour la journalisation, de sorte que vous pouvez ajouter votre propre cadre de journalisation. C'est principalement utile pour les bibliothèques. de slf4j.org :

The Simple Logging Facade for Java ou (SLF4J) est une façade simple ou une abstraction pour divers cadres de journalisation de journalisation, par exemple java.util.logging, log4j et logback, permettant ainsi à l'utilisateur l'utilisateur final de brancher le cadre de journalisation souhaité au moment du déploiement.

Pour répondre à votre question : Slf4j est en train d'être adopté par les frameworks, mais dans vos projets, vous pouvez continuer à utiliser Log4J (ou n'importe quel autre).

Answer 3

Tout d'abord, un point important : Slf4j est le frontend logging (l'API), qui peut être utilisé en dessous de la plupart des principaux systèmes de logging : log4j ou java.util.logging par exemple. Il est donc préférable de comparer sfl4j à commons-logging .

À propos de l'état de Log4j, citations de L'état de la journalisation en java (il y a un an)

Une chose que je n'avais pas réalisé est que le développement de log4j est essentiellement mort. Il en est actuellement à la version 1.2, et les plans pour la version 1.3 ont été abandonnés en faveur du développement de log4j 2.0. Cependant, il ne semble pas que la version 2.0 soit en cours de développement. Il est intéressant de noter que Ceki Gülcü, le fondateur original du projet log4j, est passé à slf4j (voir ci-dessous).

Answer 4

En regardant le page slf4j il ne semble pas que ce soit le cas remplacer log4j - il vous permettrait simplement d'utiliser le même cadre de journalisation sous-jacent (par exemple log4j) pour l'ensemble de votre application, permettant aux bibliothèques de s'y connecter automatiquement.

Il s'agit plutôt d'un remplacement pour Journalisation d'Apache Commons que log4j.

Answer 5

SLF4J a, à mon avis, l'énorme avantage de pouvoir unifier la journalisation de toutes les bibliothèques que vous utilisez grâce aux ponts qu'il fournit. Aucun des autres frameworks de journalisation ne permet cela. Cela permet aux projets de passer en douceur à SLF4J et d'ignorer les choix de frameworks de journalisation que les dépendances ont faits.