log4j vs logback

Question

Nous utilisons log4j derrière un wrapper fait maison. Nous prévoyons d'utiliser beaucoup plus de fonctionnalités de celui-ci maintenant.

Devons-nous faire une mise à jour vers logback ?

(Je parle du cadre de travail, pas d'une façade comme SLF4J).

Answer 1

Logback met en œuvre de manière native l'API SLF4J. Cela signifie que si vous utilisez logback, vous utilisez en fait l'API SLF4J. En théorie, vous pourriez utiliser les éléments internes de l'API logback directement pour la journalisation, mais cela est fortement déconseillé. Toute la documentation de logback et les exemples sur les loggers sont écrits en termes d'API SLF4J.

Ainsi, en utilisant logback, vous utiliserez SLF4J et si, pour une raison quelconque, vous souhaitez revenir à log4j, vous pourrez le faire en quelques minutes en plaçant simplement slf4j-log4j12.jar dans le chemin de vos classes.

Lors de la migration de logback vers log4j, les parties spécifiques de logback, spécifiquement celles contenues dans logback.xml devra encore être migré vers son équivalent log4j, à savoir log4j.properties . Lors de la migration dans l'autre sens, la configuration de log4j, à savoir log4j.properties doit être converti en son équivalent logback. Il existe un outil en ligne pour ça. La quantité de travail impliquée dans la migration des fichiers de configuration est beaucoup moins que le travail nécessaire pour migrer les appels de logger disséminés dans tout le code source de votre logiciel et ses dépendances.

Answer 2

Vous devriez ? Oui .

Pourquoi ? Log4J a été essentiellement déprécié par Logback .

C'est urgent ? Peut-être pas.

Est-ce indolore ? Probablement, mais cela peut dépendre de vos déclarations d'enregistrement.

Notez que si vous voulez vraiment tirer pleinement parti de LogBack (ou de SLF4J), vous devez vraiment écrire les déclarations de journalisation appropriées . Cela présente des avantages tels qu'un code plus rapide en raison de l'évaluation paresseuse, et moins de lignes de code car vous pouvez éviter les gardes.

Enfin, je recommande vivement SLF4J. (Pourquoi recréer la roue avec votre propre façade ?)

Answer 3

Je ne réponds pas exactement à votre question, mais si vous pouviez vous éloigner de votre propre wrapper, alors il y a Facade de journalisation simple pour Java (SLF4J) qu'Hibernate a maintenant adopté (au lieu de la journalisation commons).

SLF4J ne souffre d'aucun des problèmes de chargeur de classes ou de fuites de mémoire observés avec Jakarta Commons Logging (JCL).

SLF4J supporte la journalisation JDK, log4j et logback. Il devrait donc être assez facile de passer de log4j à logback lorsque le moment sera venu.

Edit : Excuses pour ne pas avoir été clair. Je suggérais d'utiliser SLF4J pour s'isoler et ne pas avoir à faire un choix difficile entre log4j ou logback.

Answer 4

Votre décision doit être basée sur

• votre besoin réel de ces "caractéristiques supplémentaires" ; et
• le coût prévu de la mise en œuvre du changement.

Vous devez résister à l'envie de changer d'API juste parce que c'est "plus nouveau, plus brillant, meilleur". Je suis une politique de "si ce n'est pas cassé, ne le bousculez pas".

Si votre application nécessite un cadre de journalisation très sophistiqué, vous pouvez vous demander pourquoi.

Answer 5

Dans le monde de la journalisation, il existe des façades (comme Apache Commons Logging, slf4j ou même l'API Log4j 2.0) et des implémentations (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

En gros, vous devriez remplacer votre wrapper maison par slf4j SI et seulement SI vous n'en êtes pas satisfait pour une raison quelconque. Alors qu'Apache Commons Logging ne fournit pas vraiment une API moderne, slf4j et la nouvelle façade Log4j 2 le font. Étant donné qu'un grand nombre d'applications utilisent slf4j comme wrapper, il peut être judicieux de l'utiliser.

slf4j fournit un certain nombre de sucre API agréable, comme cet exemple de slf4j docs :

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

C'est une substitution de variable. Ceci est également supporté par Log4j 2.

Cependant, vous devez savoir que slf4j est développé par QOS qui gère également logback. Log4j 2.0 fait partie de la Apache Software Foundation. Au cours des trois dernières années, une communauté dynamique et active s'y est à nouveau développée. Si vous appréciez l'Open Source tel qu'il est fait par l'Apache Software Foundation avec toutes ses garanties, vous pourriez reconsidérer l'utilisation de slf4j en faveur de l'utilisation directe de Log4j 2.

Veuillez noter :

Dans le passé, log4j 1 n'était pas activement maintenu alors que Logback l'était. Mais aujourd'hui, les choses sont différentes. Log4j 2 est activement maintenu et sort sur un calendrier presque régulier. Il inclut également de nombreuses fonctionnalités modernes et -imho- fait quelques choses de mieux que Logback. C'est parfois une simple question de goût et vous devez tirer vos propres conclusions.

J'ai écrit un bref aperçu des nouvelles fonctionnalités de Log4j 2.0 : http://www.grobmeier.de/the-new-log4j-2-0-05122012.html

En lisant, vous verrez que Log4j 2 a été inspiré par Logback mais aussi par d'autres frameworks de journalisation. Mais la base de code est différente ; elle ne partage presque rien avec Log4j 1 et zéro avec Logback. Cela a conduit à quelques améliorations comme par exemple Log4j 2 fonctionne avec des bytestreams au lieu de Strings sous le capot. Il ne perd pas non plus les événements lors de la reconfiguration.

Log4j 2 peut enregistrer à une vitesse supérieure à celle des autres frameworks que je connais : http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

Et pourtant, la communauté des utilisateurs semble être beaucoup plus importante que celle de Logbacks : http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

Cela dit, la meilleure idée est de choisir le cadre de journalisation qui correspond le mieux à ce que vous voulez réaliser. Je ne choisirais pas un framework complet si je voulais désactiver la journalisation dans un environnement de production et n'effectuer qu'une journalisation de base dans mon application. Cependant, si vous voulez en faire un peu plus avec la journalisation, il suffit de regarder les fonctionnalités qui sont fournies par les frameworks et leurs développeurs. Alors que vous obtenez un support commercial pour Logback à travers QOS (j'ai entendu), il n'y a actuellement aucun support commercial pour Log4j 2. D'un autre côté, si vous avez besoin de faire de la journalisation d'audit et si vous avez besoin des hautes performances fournies par les appenders asynchrones, il est tout à fait logique d'utiliser Log4j 2.

Veuillez noter que malgré tout le confort qu'elles procurent, les façades consomment toujours un peu de performance. Cela ne vous affecte peut-être pas du tout, mais si vous avez peu de ressources, vous devrez peut-être économiser tout ce que vous pouvez avoir.

Sans mieux connaître vos besoins, il est presque impossible de donner une recommandation. Simplement : ne changez pas de fournisseur simplement parce que beaucoup de gens le font. Changez seulement parce que vous en voyez la valeur. Et l'argument selon lequel log4j est mort ne compte plus. C'est vivant, et c'est chaud.

AVERTISSEMENT : Je suis actuellement vice-président des services de journalisation d'Apache et je suis également impliqué dans log4j.