log4j vs logback
Nous utilisons log4j derrière un wrapper fait à la main. Nous prévoyons d’utiliser beaucoup plus de fonctionnalités de ce logiciel maintenant.
Devrions-nous mettre à jour à la connexion?
(Je veux dire le cadre pas une façade comme SLF4J)
Logback implémente de manière native l'API SLF4J. Cela signifie que si vous utilisez la consignation, vous utilisez en réalité l'API SLF4J. Vous pouvez théoriquement utiliser les composants internes de l'API de consignation directement pour la consignation, mais cela est fortement déconseillé. Toute la documentation de consignation et les exemples d’enregistreurs sont écrits en termes d’API SLF4J.
Donc, en utilisant logback, vous utiliseriez réellement SLF4J et si, pour une raison quelconque, vous vouliez revenir à log4j, vous pouvez le faire en quelques minutes en déposant simplement slf4j-log4j12.jar sur votre chemin de classe.
Lors de la migration de logback vers log4j, les parties spécifiques au journal, en particulier celles contenues dans logback.xml , doivent toujours être migrées vers leur équivalent log4j, c'est-à-dire log4j.properties . Lors de la migration dans l'autre sens, la configuration de log4j, c'est-à-dire log4j.properties , devra être convertie en son équivalent de journal. Il existe un outil en ligne pour cela. La quantité de travail nécessaire à la migration des fichiers de configuration est très inférieure à celle nécessaire pour migrer les appels de l'enregistreur disséminés dans l'ensemble du code source de votre logiciel et de ses dépendances.
Devrais-tu? Oui .
Pourquoi? Log4J a été essentiellement déconseillé par Logback .
Est-ce urgent? Peut être pas.
Est-ce indolore? Probablement, mais cela peut dépendre de vos instructions de journalisation.
Notez que si vous voulez vraiment tirer le meilleur parti de LogBack (ou de SLF4J), vous devez alors écrire instructions de journalisation appropriées . Cela produira des avantages tels qu'un code plus rapide en raison d'une évaluation paresseuse et moins de lignes de code car vous pouvez éviter les gardes.
Enfin, je recommande fortement SLF4J. (Pourquoi recréer la roue avec votre propre façade?)
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).
Fondamentalement, vous devriez remplacer votre emballage personnalisé par slf4j SI et seulement SI vous n’êtes pas satisfait pour une raison quelconque. Bien que Apache Commons Logging ne fournisse pas vraiment une API moderne, slf4j et la nouvelle façade Log4j 2 le fournissent. Étant donné que de nombreuses applications utilisent slf4j en tant que wrapper, il peut être judicieux de l'utiliser.
slf4j donne un certain nombre de sucres Nice API, comme dans cet exemple tiré de la documentation de slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
C'est une substitution variable. Ceci est également supporté par Log4j 2.
Cependant, vous devez savoir que slf4j est développé par QOS qui gère également la consignation. Log4j 2.0 est cuit dans Apache Software Foundation. Au cours des trois dernières années, une communauté dynamique et active s’y est développée. Si vous appréciez l'Open Source tel qu'il est conçu par Apache Software Foundation avec toutes ses garanties, vous pouvez reconsidérer l'utilisation de slf4j en faveur de l'utilisation directe de Log4j 2.
Notez s'il vous plaît:
Dans le passé, log4j 1 n’était pas activement maintenu, contrairement à Logback. Mais aujourd'hui, les choses sont différentes. Log4j 2 est activement maintenu et publie à un calendrier presque régulier. Il comprend également de nombreuses fonctionnalités modernes et -imho- rend certaines choses meilleures que Logback. C'est parfois juste une question de goût et vous devriez 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 également par d’autres frameworks de journalisation. Mais la base de code est différente. il ne partage presque rien avec Log4j 1 et zéro avec Logback. Cela a conduit à certaines améliorations, comme dans l'exemple de Log4j 2, qui utilise des bytestreams au lieu de Strings sous le capot. En outre, il ne perd pas les événements lors de la reconfiguration.
Log4j 2 peut se connecter à une vitesse supérieure à celle des autres frameworks que je connais: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
Et toujours la communauté des utilisateurs semble être beaucoup plus grande que Logbacks: http://www.grobmeier.de/Apache-log4j-is-the-leading-logging-framework-06082013.html
Cela dit, la meilleure idée est de choisir les cadres de journalisation qui correspondent le mieux à vos objectifs. Je ne changerais pas de structure complète si je désactivais la journalisation dans un environnement de production et effectuais une journalisation de base dans mon application. Cependant, si vous en faites un peu plus avec la journalisation, il suffit de regarder les fonctionnalités fournies par les frameworks et leurs développeurs. Bien que vous obteniez un support commercial pour Logback via QOS (j'ai entendu dire), il n’existe actuellement aucun support commercial pour Log4j 2. Par contre, si vous devez effectuer une journalisation d’audit et que vous avez besoin de performances élevées fournies par les ajouts asynchrones, il est logique de: vérifiez log4j 2.
S'il vous plaît noter que malgré tout le confort qu'ils fournissent, les façades mangent toujours un peu de performance. Cela ne vous concerne peut-être pas du tout, mais si vous avez peu de ressources, vous devrez peut-être sauvegarder tout ce que vous pouvez avoir.
Sans mieux connaître vos besoins, il est presque impossible de faire une recommandation. Juste: ne changez pas simplement parce que beaucoup de gens changent. Basculez uniquement parce que vous en voyez la valeur. Et l'argumentation selon laquelle log4j est mort ne compte plus. C'est vivant et il fait chaud.
AVERTISSEMENT: Je suis actuellement VP, Apache Logging Services et impliqué dans log4j également.
Vous ne répondez pas exactement à votre question, mais si vous pouviez vous éloigner de votre propre emballage, il y aurait alors Simple Logging Facade pour Java (SLF4J) lequel Hibernate a maintenant basculé to (au lieu de la journalisation commune).
SLF4J ne souffre d'aucun des problèmes de chargeur de classe ni de fuites de mémoire observés avec Jakarta Commons Logging (JCL).
SLF4J prend en charge la journalisation JDK, log4j et la consignation. Il devrait donc être assez facile de passer de log4j à logback lorsque le moment est opportun.
Edit: Des aplogies que je n'avais pas clarifiées. Je proposais d'utiliser SLF4J pour vous éviter d'avoir à faire un choix difficile entre log4j ou logback.
Votre décision devrait être basée sur
- votre besoin réel de ces "plus de fonctionnalités"; et
- le coût prévu de la mise en œuvre du changement.
Vous devriez résister à l'envie de changer les API simplement parce que c'est "plus récent, plus brillant, mieux". Je suis une politique de "si ce n'est pas cassé, ne pas le botter."
Si votre application nécessite un cadre de journalisation très sophistiqué, vous pouvez envisager pourquoi.
Un projet mature ou même un projet en profondeur dans les étapes de développement perdrait probablement plus que le gain d’une telle mise à niveau, IMHO. Logback est certainement beaucoup plus avancé dans une série de points, mais pas dans une certaine mesure pour un remplacement complet dans un système en fonctionnement. Je considérerais certainement la consignation pour un nouveau développement, mais le log4j existant est assez bon et mûr pour tout ce qui a déjà été publié et rencontré par l'utilisateur final. C'est très subjectif, vous devriez voir le coût vous-même.