Logback semble très similaire à la journalisation jakarta commons - quelles sont les principales différences?
matt b
12
SLF4J (qui est la façade) ressemble à commons.logging. La principale différence est que SLF4J utilise la liaison statique tandis que commons.logging utilise une stratégie de résolution. Logback (l'implémentation "native" (c'est-à-dire qu'il n'y a pas de couche wrapper supplémentaire) de la façade) est comparable à LOG4J mais possède une API plus riche.
Huxi
Réponses:
190
Logback implémente nativement l'API SLF4J. Cela signifie que si vous utilisez logback, vous utilisez en fait l'API SLF4J. Vous pouvez théoriquement utiliser les composants internes de l'API logback directement pour la journalisation, mais cela est fortement déconseillé. Toute la documentation de connexion et les exemples sur les enregistreurs sont écrits en termes de l'API SLF4J.
Donc, en utilisant logback, vous utiliseriez en fait SLF4J et si pour une raison quelconque vous vouliez revenir à log4j, vous pourriez 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 de logback, en particulier celles contenues dans le fichier de configuration logback.xml , devront encore être migrées vers son équivalent log4j, c'est-à-dire log4j.properties . Lors de la migration dans l'autre sens, la configuration log4j, c'est-à-dire log4j.properties , devra être convertie en son équivalent logback. Il existe un outil en ligne pour cela. La quantité de travail impliquée dans la migration des fichiers de configuration est bien inférieure au travail requis pour migrer les appels de journalisation disséminés dans tout le code source de votre logiciel et ses dépendances.
C'est une excellente occasion de parler au développeur d'un logiciel aussi populaire. Merci Ceki pour log4j.
Srujan Kumar Gulla
7
Avertissement: Ce gars est le développeur original de tous Log4j, SLF4J et Logback. Mais ne fonctionne plus pour Log4j.
Victor Stafusa
56
Devrais-tu? Oui .
Pourquoi? Log4J est essentiellement obsolète 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 profiter pleinement de LogBack (ou SLF4J), vous devez vraiment écrire des instructions de journalisation appropriées . Cela donnera des avantages comme un code plus rapide en raison de l'évaluation paresseuse et moins de lignes de code parce que vous pouvez éviter les gardes.
Enfin, je recommande vivement SLF4J. (Pourquoi recréer la roue avec votre propre façade?)
Remarque: Le projet log4j ne considère pas log4j comme obsolète.
Thorbjørn Ravn Andersen
17
La terminologie devrait être clarifiée; sans équivoque, l' auteur du projet log4j considère que logback est le successeur de log4j. C'est le même auteur des deux projets, donc son opinion devrait avoir un certain poids; le "projet log4j" lui-même ne "considère" rien. Le groupe actuel de personnes associées à log4j a des opinions divergentes (certaines sont en fait d'accord, certaines sont en désaccord sans surprise). Avec un peu plus d'histoire derrière nous (3 ans après le commentaire original), SLF4J + Logback continuent de gagner du terrain sur Log4j.
michael
@michael_n Veuillez noter que Log4j 1 n'a PAS été écrit par une seule personne. C'est faux de dire le "même auteur". Ceki est un auteur important, pas de doute, mais pas le seul. En fait, beaucoup de gens ont contribué à faire de Log4j 1 ce qu'il est.
Christian
@Christian "n'était PAS écrit ..." bien sûr, cela devrait être sous-entendu pour tout projet apache mature (et ma qualification, "le groupe actuel de personnes associées à log4j"); néanmoins, si je pouvais éditer le commentaire, je dirais «à l' origine », comme le stipule également l'article de wikipedia. Re: "En fait, beaucoup de gens ont aidé à faire de Log4j 1 ce qu'il est" , c'est absolument, équivoqueement vrai (c'est-à-dire pour le meilleur ou pour le pire); et aussi, d'une certaine manière, contribué à la création de slf4j + logback :-)
michael
3
Alors, qu'y a-t-il pour vous tous de vous battre pour telle ou telle bibliothèque de journalisation? Pourquoi essayons-nous de tuer / promouvoir les bibliothèques? Au moins, fournissez un raisonnement rationnel POURQUOI l'un est meilleur que l'autre. Mon Dieu, Stack Overflow est un gâchis.
Utilisateur
48
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 propre wrapper par slf4j IF 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 fournissent. Étant donné que de nombreuses applications utilisent slf4j comme wrapper, il peut être judicieux de l'utiliser.
slf4j donne un certain nombre de sucre API sympa, comme cet exemple de la documentation slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
C'est une substitution variable. Ceci est également pris en charge par Log4j 2.
Cependant, vous devez être conscient que slf4j est développé par QOS qui gère également le retour de connexion. Log4j 2.0 est intégré à Apache Software Foundation. Au cours des trois dernières années, une communauté dynamique et active s'est de nouveau développée. Si vous appréciez l'Open Source comme cela est fait par l'Apache Software Foundation avec toutes ses garanties, vous pouvez reconsidérer l'utilisation de slf4j en faveur d'utiliser Log4j 2 directement.
Notez s'il vous plaît:
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 comprend également de nombreuses fonctionnalités modernes et -imho- rend deux choses meilleures que Logback. C'est parfois juste une question de goût et vous devriez tirer vos propres conclusions.
A la lecture, 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; il ne partage presque rien avec Log4j 1 et zéro avec Logback. Cela a conduit à quelques améliorations comme dans l'exemple Log4j 2 fonctionne avec bytestreams au lieu de Strings sous le capot. De plus, il ne perd pas d'événements lors de la reconfiguration.
Cela dit, la meilleure idée est de choisir les cadres de journalisation qui correspondent le mieux à ce que vous souhaitez réaliser. Je ne changerais pas de cadre complet si je désactivais la journalisation dans l'environnement de production et effectuais simplement une journalisation de base dans mon application. Cependant, si vous faites un peu plus avec la journalisation, regardez simplement les fonctionnalités fournies par les frameworks et leurs développeurs. Bien que vous bénéficiez d'un support commercial pour Logback via QOS (j'ai entendu dire), il n'y a actuellement aucun support commercial pour Log4j 2. D'un autre côté, si vous avez besoin de faire une journalisation d'audit et que vous avez besoin de hautes performances fournies par les appenders asynchrones, il est très logique de vérifier log4j 2.
Attention malgré tout le confort qu'elles procurent, les façades mangent toujours un peu de performance. Cela ne vous affecte peut-être pas du tout, mais si vous manquez de ressources, vous devrez peut-être sauvegarder tout ce que vous pouvez avoir.
Sans mieux connaître vos besoins, il est presque impossible de donner une recommandation. Juste: ne changez pas simplement parce que beaucoup de gens changent. Ne changez que parce que vous en voyez la valeur. Et l'argumentation selon laquelle log4j est mort ne compte plus. Il est vivant et il fait chaud.
AVIS DE NON-RESPONSABILITÉ: Je suis actuellement vice-président des services de journalisation Apache et je suis également impliqué dans log4j.
Cela ne répond pas exactement à votre question, mais si vous pouviez vous éloigner de votre propre wrapper, il y a Simple Logging Facade pour Java (SLF4J) sur lequel Hibernate est maintenant passé (au lieu de la journalisation commune).
SLF4J ne souffre d'aucun des problèmes de chargeur de classe ou de fuites de mémoire observés avec Jakarta Commons Logging (JCL).
SLF4J prend en charge la journalisation JDK, log4j et la journalisation. Il devrait donc être assez facile de passer de log4j à logback lorsque le moment est venu.
Edit: Aplogies que je ne m'étais pas fait comprendre. Je suggérais d'utiliser SLF4J pour vous isoler d'avoir à faire un choix difficile entre log4j ou logback.
Je connais SLF4J. Mais j'ai demandé le cadre de journalisation, pas la façade!
4
Toutes mes excuses. Ce que je suggérais, c'est que si vous utilisiez SLF4J au lieu de votre propre façade personnalisée, alors passer de log4j à logback serait moins douloureux?
toolkit
Quelle est la source de cette citation? La journalisation Commons est un composant qui a fait ses preuves. Je n'ai jamais eu de fuite de mémoire avec.
Kshitiz Sharma
1
@KshitizSharma - à partir du lien de documentation SLF4J que j'ai fourni: slf4j.org/manual.html
toolkit
13
Votre décision doit être basée sur
votre besoin réel de ces "fonctionnalités supplémentaires"; et
votre coût prévu de 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 le frappez pas."
Si votre application nécessite une infrastructure de journalisation très sophistiquée, vous pouvez vous demander pourquoi.
Un projet mature ou même un projet en profondeur dans les étapes de développement perdrait probablement plus que de gagner d'une telle mise à niveau, à mon humble avis. Logback est certainement beaucoup plus avancé dans un tableau de points, mais pas dans une mesure pour un remplacement complet dans un système en état de marche. J'envisagerais certainement de se connecter pour un nouveau développement, mais log4j existant est assez bon et mature pour tout ce qui est déjà publié et rencontré par l'utilisateur final. C'est très subjectif, vous devriez voir le coût vous-même.
Réponses:
Logback implémente nativement l'API SLF4J. Cela signifie que si vous utilisez logback, vous utilisez en fait l'API SLF4J. Vous pouvez théoriquement utiliser les composants internes de l'API logback directement pour la journalisation, mais cela est fortement déconseillé. Toute la documentation de connexion et les exemples sur les enregistreurs sont écrits en termes de l'API SLF4J.
Donc, en utilisant logback, vous utiliseriez en fait SLF4J et si pour une raison quelconque vous vouliez revenir à log4j, vous pourriez 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 de logback, en particulier celles contenues dans le fichier de configuration logback.xml , devront encore être migrées vers son équivalent log4j, c'est-à-dire log4j.properties . Lors de la migration dans l'autre sens, la configuration log4j, c'est-à-dire log4j.properties , devra être convertie en son équivalent logback. Il existe un outil en ligne pour cela. La quantité de travail impliquée dans la migration des fichiers de configuration est bien inférieure au travail requis pour migrer les appels de journalisation disséminés dans tout le code source de votre logiciel et ses dépendances.
la source
Devrais-tu? Oui .
Pourquoi? Log4J est essentiellement obsolète 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 profiter pleinement de LogBack (ou SLF4J), vous devez vraiment écrire des instructions de journalisation appropriées . Cela donnera des avantages comme un code plus rapide en raison de l'évaluation paresseuse et moins de lignes de code parce que vous pouvez éviter les gardes.
Enfin, je recommande vivement SLF4J. (Pourquoi recréer la roue avec votre propre façade?)
la source
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 propre wrapper par slf4j IF 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 fournissent. Étant donné que de nombreuses applications utilisent slf4j comme wrapper, il peut être judicieux de l'utiliser.
slf4j donne un certain nombre de sucre API sympa, comme cet exemple de la documentation slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);C'est une substitution variable. Ceci est également pris en charge par Log4j 2.
Cependant, vous devez être conscient que slf4j est développé par QOS qui gère également le retour de connexion. Log4j 2.0 est intégré à Apache Software Foundation. Au cours des trois dernières années, une communauté dynamique et active s'est de nouveau développée. Si vous appréciez l'Open Source comme cela est fait par l'Apache Software Foundation avec toutes ses garanties, vous pouvez reconsidérer l'utilisation de slf4j en faveur d'utiliser Log4j 2 directement.
Notez s'il vous plaît:
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 comprend également de nombreuses fonctionnalités modernes et -imho- rend deux choses meilleures que Logback. C'est parfois juste une question de goût et vous devriez tirer vos propres conclusions.
J'ai rédigé un bref aperçu des nouvelles fonctionnalités de Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
A la lecture, 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; il ne partage presque rien avec Log4j 1 et zéro avec Logback. Cela a conduit à quelques améliorations comme dans l'exemple Log4j 2 fonctionne avec bytestreams au lieu de Strings sous le capot. De plus, il ne perd pas d'événements lors de la reconfiguration.
Log4j 2 peut se connecter à une vitesse plus élevée que les 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 à ce que vous souhaitez réaliser. Je ne changerais pas de cadre complet si je désactivais la journalisation dans l'environnement de production et effectuais simplement une journalisation de base dans mon application. Cependant, si vous faites un peu plus avec la journalisation, regardez simplement les fonctionnalités fournies par les frameworks et leurs développeurs. Bien que vous bénéficiez d'un support commercial pour Logback via QOS (j'ai entendu dire), il n'y a actuellement aucun support commercial pour Log4j 2. D'un autre côté, si vous avez besoin de faire une journalisation d'audit et que vous avez besoin de hautes performances fournies par les appenders asynchrones, il est très logique de vérifier log4j 2.
Attention malgré tout le confort qu'elles procurent, les façades mangent toujours un peu de performance. Cela ne vous affecte peut-être pas du tout, mais si vous manquez de ressources, vous devrez peut-être sauvegarder tout ce que vous pouvez avoir.
Sans mieux connaître vos besoins, il est presque impossible de donner une recommandation. Juste: ne changez pas simplement parce que beaucoup de gens changent. Ne changez que parce que vous en voyez la valeur. Et l'argumentation selon laquelle log4j est mort ne compte plus. Il est vivant et il fait chaud.
AVIS DE NON-RESPONSABILITÉ: Je suis actuellement vice-président des services de journalisation Apache et je suis également impliqué dans log4j.
la source
Cela ne répond pas exactement à votre question, mais si vous pouviez vous éloigner de votre propre wrapper, il y a Simple Logging Facade pour Java (SLF4J) sur lequel Hibernate est maintenant passé (au lieu de la journalisation commune).
SLF4J prend en charge la journalisation JDK, log4j et la journalisation. Il devrait donc être assez facile de passer de log4j à logback lorsque le moment est venu.
Edit: Aplogies que je ne m'étais pas fait comprendre. Je suggérais d'utiliser SLF4J pour vous isoler d'avoir à faire un choix difficile entre log4j ou logback.
la source
Votre décision doit être basée sur
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 le frappez pas."
Si votre application nécessite une infrastructure de journalisation très sophistiquée, vous pouvez vous demander pourquoi.
la source
Un projet mature ou même un projet en profondeur dans les étapes de développement perdrait probablement plus que de gagner d'une telle mise à niveau, à mon humble avis. Logback est certainement beaucoup plus avancé dans un tableau de points, mais pas dans une mesure pour un remplacement complet dans un système en état de marche. J'envisagerais certainement de se connecter pour un nouveau développement, mais log4j existant est assez bon et mature pour tout ce qui est déjà publié et rencontré par l'utilisateur final. C'est très subjectif, vous devriez voir le coût vous-même.
la source