Pourquoi diable Ceki a-t-il créé 3 frameworks de journalisation !!! c'est de la folie ...
mP.
6
@mP. - log4j a été le premier, puis un désaccord est survenu, et slf4j + logback a été écrit. slf4j est l' API et enregistre l'implémentation de l'API. Indépendamment de tout le reste, slf4j est extrêmement utile.
Thorbjørn Ravn Andersen
3
Pour plus de détails sur les raisons pour lesquelles Ceki Gülcü a créé SLF4J + Logback, consultez la discussion Devoxx suivante: parleys.com/#st=5&id=1701
bitek
La meilleure chose à en tirer est l'API slf4j qui, espérons-le, unifiera le monde de la journalisation. Je pense que Logback n'a pas encore atteint une masse critique avec les développeurs.
Thorbjørn Ravn Andersen
Réponses:
86
Dans l'ordre chronologique d'apparition des api (pour autant que je sache):
Log4j parce que presque tout le monde l'utilise (d'après mon expérience)
Journalisation Commons parce que les projets open source l'utilisent (afin qu'ils puissent s'intégrer à n'importe quel cadre de journalisation utilisé dans la solution intégrée); particulièrement valable si vous êtes une API / Framework / OSS et que vous comptez sur d'autres packages qui utilisent Commons Logging.
Commons Logging parce que vous ne voulez pas vous "verrouiller" sur un cadre de journalisation particulier (donc à la place, vous vous verrouillez sur ce que Commons Logging vous donne à la place) - Je ne pense pas qu'il soit judicieux de décider d'utiliser ce point comme raison.
Journalisation Java car vous ne souhaitez pas ajouter de fichier jar supplémentaire.
SLF4j car il est plus récent que Commons Logging et fournit une journalisation paramétrée:
logger.debug("The entry is {}.", entry);//which expands effectively toif(logger.isDebugEnabled()){// Note that it's actually *more* efficient than this - see Huxi's comment below...
logger.debug("The entry is "+ entry +".");}
Logback car il est plus récent que log4j et encore une fois, prend en charge la journalisation paramétrée, car il implémente directement SLF4j
SLF4j / Logback parce qu'il est écrit par le même gars qui a fait log4j, donc il l'a amélioré (selon Ken G - merci. Cela semble convenir en regardant leurs articles précédents )
SLF4j, car ils publient également un adaptateur log4j pour que vous n'ayez pas à "désactiver" log4j dans un code plus ancien - faites simplement en sorte que log4j.properties utilise SLF4j et sa configuration
Autant que je sache, l'idée derrière la journalisation commune est qu'elle devrait être utilisée dans les bibliothèques. De cette façon, la bibliothèque peut toujours utiliser le même cadre de journalisation (via la journalisation commune) que l'application d'hébergement utilise.
Joachim Sauer
Merci beaucoup à Loki pour la question. Je sais maintenant que je n'utiliserai plus log4j comme framework par défaut. SLF4j FTW! Merci également à Ken G pour avoir souligné que SLF4j est écrit par le même gars que log4j
Stephen
3
Le commentaire dans votre exemple de code n'est pas correct à 100%. Le formatage réel du message est effectué paresseusement par Logback donc cela ne se produira que si l'événement est vraiment géré par un appender et que l'appender a besoin du message formaté - ce qui ne se produirait pas dans le cas, par exemple, d'un SocketAppender puisque l'événement est sérialisé à l'aide de le modèle de message inchangé + les arguments sous forme de chaînes. Je suppose que cela dépend simplement de la façon dont vous définissez «effectivement». Il émettrait certainement le même message (du moins si l'entrée et l'objet sont les mêmes;)) alors pardonnez-moi mon pinaillage.
Huxi
6
SLF4J n'est en fait qu'une API qui se trouve au-dessus d'autres frameworks de journalisation. Similaire à l'objectif de Commons Logging, mais plus intuitif d'après mon expérience.
James McMahon
37
Je trouve que la journalisation en Java est confuse, incohérente, mal documentée et surtout aléatoire. De plus, il existe une grande similitude entre ces frameworks de journalisation, ce qui entraîne une duplication des efforts et une confusion quant à l'environnement de journalisation dans lequel vous vous trouvez réellement. En particulier, si vous travaillez dans une pile d'applications Web Java sérieuse, vous êtes souvent plusieursdes environnements de journalisation en même temps; (par exemple, hibernate peut utiliser log4j et tomcat java.util.logging). Apache commons est destiné à relier différents frameworks de journalisation, mais ajoute simplement plus de complexité. Si vous ne le savez pas à l'avance, c'est complètement déconcertant. Pourquoi mes messages de journal ne s'impriment-ils pas sur la console, etc.? Ohh parce que je regarde les journaux Tomcat, et non log4j. Ajoutant encore une autre couche de complexité, le serveur d'applications peut avoir des configurations de journalisation globale qui peuvent ne pas reconnaître les configurations locales pour une application Web particulière. Enfin, tous ces cadres de journalisation sont TROP COMPLIQUÉS. La connexion à Java a été un désordre désorganisé, laissant les développeurs comme moi frustrés et confus.
Les premières versions de Java n'avaient pas de cadre de journalisation intégré conduisant à ce scénario.
Est-ce une réponse? Cela ressemble plus à une diatribe.
Michael Myers
15
Je suis désolé. Il est un peu d'un coup de gueule. Mais c'est aussi une réponse convaincante à "Quoi de neuf avec la journalisation en Java?". La réponse, en bref, est qu'il est profondément brisé.
Julien Chastang
1
eh bien ça ne vaut pas un vote de -1; P Mais quelque chose à méditer.
guyumu
21
Les problèmes ont commencé lorsque Sun a ajouté java.util.logging à Java 1.4. Avant cela, LOG4J était bien établi et largement utilisé. Après cela, il était nécessaire d'utiliser des wrappers pour prendre en charge à la fois LOG4J et java.util.logging. De plus, puisque jul est contenu dans le package java. *, Il ne peut pas être remplacé par un échange de JAR - ce qui est la façon dont SLF4J relie les autres frameworks. C'était probablement la pire idée de Sun jamais ... et cela a finalement conduit à l'hypothèse erronée qu'un «bon citoyen de Java» devrait utiliser jul.
Huxi
4
@Huxi, je maintiens que l'API Calendar était pire. Pour défendre Sun, ce n'était pas leur code, mais venait de Taglient.
Thorbjørn Ravn Andersen
22
Il y a un point important qui n'a pas été mentionné auparavant:
SLF4J (et Logback et LOG4J en tant que backend de journalisation) prennent en charge ce que l'on appelle un contexte de diagnostic mappé (MDC, voir javadoc et documentation ).
Il s'agit essentiellement d'une Map <String, String> locale au thread que vous pouvez utiliser pour ajouter des informations contextuelles supplémentaires à votre événement de journalisation. L'état actuel du MDC est associé à chaque événement.
Cela peut être extrêmement utile si vous y mettez des éléments tels que le nom d'utilisateur et l'URL de la requête (dans le cas d'une application Web). Cela peut être fait automatiquement à l'aide d'un filtre, par exemple.
Dans notre projet d'entreprise, nous utilisons LOG4j et il est très facile à utiliser comme Stephen l'a montré dans son exemple. Nous avons également écrit nos propres classes de modèles pour LOG4j afin que vous puissiez créer vos propres schémas de fichiers de sortie. Vous pouvez décrire à quoi devrait ressembler votre fichier journal. Il est possible d'améliorer les classes log4j d'origine.
Vous pouvez modifier toutes les propriétés de LOG4j dans un fichier log4j.properties, de sorte que vous pouvez utiliser différents fichiers pour différents projets.
La journalisation Java n'est pas ma préférence, mais cela pourrait être dû au fait que j'utilise log4j depuis le début.
L' aperçu de Commons Logging donne la raison de son existence: la journalisation à partir du code de la bibliothèque, lorsque vous n'avez aucun contrôle sur le cadre de journalisation sous-jacent. Très important pour les différents projets Apache, qui seront liés à des applications extérieures. Peut-être pas si important pour les projets informatiques internes, où vous avez un contrôle total.
Cela dit, j'écris à Commons Logging, comme le font beaucoup d'autres développeurs que je connais. La raison est de minimiser le bagage mental: vous pouvez changer de projet ou de travail, et ne pas avoir à apprendre un nouveau cadre (à condition que le nouveau travail / projet utilise également CL, et / ou que vous puissiez les convaincre de passer à lui).
En outre, il y a une certaine valeur à créer vos propres wrappers autour du framework que vous utilisez. Comme décrit ici , j'aime utiliser un objet LogWrapper pour fournir une stringification personnalisée (important) et minimiser l'encombrement visuel des instructions de journalisation (moins important).
Il y a aussi un pont commons.logging => SLF4J qui peut être utilisé pour acheminer toute la journalisation CL sur SLF4J. SLF4J prend en charge le pontage de commons.logging, LOG4J et (un peu encombrant, mais aussi bon que possible) java.util.logging afin que tous les journaux se retrouvent dans le backend SLF4J que vous utiliserez. Voir slf4j.org/legacy.html J'utiliserais Logback, btw, mais vous pourriez dire que je suis partial.
Huxi
2
En général, j'utiliserais par défaut Log4J.
J'utiliserais Java Logging si cela ne me dérangeait pas une dépendance à Java 1.4, mais j'utiliserais toujours Log4J de préférence.
J'utiliserais Commons Logging si j'améliorais quelque chose qui l'utilisait déjà.
Cela ne vous dérange pas une dépendance sur 1.4 ?? Même le 1.4 a atteint la fin de sa durée de vie.
Tom Hawtin - tackline
2
@Tom He signifie jdk1.4 + ne soyez pas idiot.
mP.
En fait, j'ai récemment fait du travail dans un système qui fonctionnait toujours sous jdk 1.3 :-(, et c'était il y a moins de deux ans que je maintenais pour la dernière fois un système jdk 1.2 . Trop d'endroits ne sont pas mis à jour à moins qu'ils n'aient absolument à, ils refusent simplement d'installer les mises à niveau.
Michael Rutherfurd
0
Je suggérerais de créer une façade de journalisation mince qui puisse écrire sur n'importe lequel des cadres de journalisation, à quel point le choix du moteur de support devient à peu près un point discutable.
C'est ce que fait l'exploitation forestière commune alors pourquoi réinventer la roue? Il y a aussi certains problèmes que votre façade devrait gérer comme le fait déjà la journalisation des communs.
James AN Stauffer
+1 Pour contrer l'argument de journalisation commun, certaines applications d'entreprise utilisent un enregistreur personnalisé. Cacher l'implémentation sous-jacente est toujours une bonne idée. L'emballage «mince» élimine le besoin d'un autre pot d'être emballé et n'est pas autant que réinventer.
questzen
1
Cela m'a sauvé récemment lorsque nous avons porté notre framework sur le Compact Framework (en .Net). Si nous avions eu des dépendances codées en dur sur nLog, nous aurions été foutus. Parce que nous avons utilisé cette approche, nous avons pu insérer un enregistreur nul et être heureux. Quelqu'un a voté pour moi jusqu'à 0 S'il vous plaît :-)
tsimon
3
Il en existe déjà un - jetez un œil à slf4j. C'est un wrapper léger accepté qui vous permet de changer de cadre de journalisation au démarrage de l'application en basculant les fichiers JAR sur le chemin des classes d'exécution.
déter le
1
le colmatage a sa propre façon de découvrir quel cadre il utilisera - ce n'est pas beau et plutôt alambiqué. Combien de frameworks de journalisation Ceki a-t-il créés. Il faut toujours s'efforcer de placer un niveau d'interdirection et de masquer une implémentation même si elle est obstruée par votre propre journalisation. Dans les coulisses, vous pouvez ensuite ajouter tout ce que vous désirez, comme mentionné par Travis.
Réponses:
Dans l'ordre chronologique d'apparition des api (pour autant que je sache):
la source
Je trouve que la journalisation en Java est confuse, incohérente, mal documentée et surtout aléatoire. De plus, il existe une grande similitude entre ces frameworks de journalisation, ce qui entraîne une duplication des efforts et une confusion quant à l'environnement de journalisation dans lequel vous vous trouvez réellement. En particulier, si vous travaillez dans une pile d'applications Web Java sérieuse, vous êtes souvent plusieursdes environnements de journalisation en même temps; (par exemple, hibernate peut utiliser log4j et tomcat java.util.logging). Apache commons est destiné à relier différents frameworks de journalisation, mais ajoute simplement plus de complexité. Si vous ne le savez pas à l'avance, c'est complètement déconcertant. Pourquoi mes messages de journal ne s'impriment-ils pas sur la console, etc.? Ohh parce que je regarde les journaux Tomcat, et non log4j. Ajoutant encore une autre couche de complexité, le serveur d'applications peut avoir des configurations de journalisation globale qui peuvent ne pas reconnaître les configurations locales pour une application Web particulière. Enfin, tous ces cadres de journalisation sont TROP COMPLIQUÉS. La connexion à Java a été un désordre désorganisé, laissant les développeurs comme moi frustrés et confus.
Les premières versions de Java n'avaient pas de cadre de journalisation intégré conduisant à ce scénario.
la source
Il y a un point important qui n'a pas été mentionné auparavant:
SLF4J (et Logback et LOG4J en tant que backend de journalisation) prennent en charge ce que l'on appelle un contexte de diagnostic mappé (MDC, voir javadoc et documentation ).
Il s'agit essentiellement d'une Map <String, String> locale au thread que vous pouvez utiliser pour ajouter des informations contextuelles supplémentaires à votre événement de journalisation. L'état actuel du MDC est associé à chaque événement.
Cela peut être extrêmement utile si vous y mettez des éléments tels que le nom d'utilisateur et l'URL de la requête (dans le cas d'une application Web). Cela peut être fait automatiquement à l'aide d'un filtre, par exemple.
la source
Voir aussi les réponses à la question Quelles sont les meilleures pratiques pour consigner une erreur? , surtout:
Il existe des problèmes potentiels de chargement de classe avec Commons Logging.
Log4J et SLF4J ont été développés par la même personne, apprenant des problèmes rencontrés dans la pratique avec Log4J.
la source
Dans notre projet d'entreprise, nous utilisons LOG4j et il est très facile à utiliser comme Stephen l'a montré dans son exemple. Nous avons également écrit nos propres classes de modèles pour LOG4j afin que vous puissiez créer vos propres schémas de fichiers de sortie. Vous pouvez décrire à quoi devrait ressembler votre fichier journal. Il est possible d'améliorer les classes log4j d'origine.
Vous pouvez modifier toutes les propriétés de LOG4j dans un fichier log4j.properties, de sorte que vous pouvez utiliser différents fichiers pour différents projets.
La journalisation Java n'est pas ma préférence, mais cela pourrait être dû au fait que j'utilise log4j depuis le début.
la source
L' aperçu de Commons Logging donne la raison de son existence: la journalisation à partir du code de la bibliothèque, lorsque vous n'avez aucun contrôle sur le cadre de journalisation sous-jacent. Très important pour les différents projets Apache, qui seront liés à des applications extérieures. Peut-être pas si important pour les projets informatiques internes, où vous avez un contrôle total.
Cela dit, j'écris à Commons Logging, comme le font beaucoup d'autres développeurs que je connais. La raison est de minimiser le bagage mental: vous pouvez changer de projet ou de travail, et ne pas avoir à apprendre un nouveau cadre (à condition que le nouveau travail / projet utilise également CL, et / ou que vous puissiez les convaincre de passer à lui).
En outre, il y a une certaine valeur à créer vos propres wrappers autour du framework que vous utilisez. Comme décrit ici , j'aime utiliser un objet LogWrapper pour fournir une stringification personnalisée (important) et minimiser l'encombrement visuel des instructions de journalisation (moins important).
la source
En général, j'utiliserais par défaut Log4J.
J'utiliserais Java Logging si cela ne me dérangeait pas une dépendance à Java 1.4, mais j'utiliserais toujours Log4J de préférence.
J'utiliserais Commons Logging si j'améliorais quelque chose qui l'utilisait déjà.
la source
Je suggérerais de créer une façade de journalisation mince qui puisse écrire sur n'importe lequel des cadres de journalisation, à quel point le choix du moteur de support devient à peu près un point discutable.
la source