Qu'est-ce qui se passe avec la journalisation en Java ?

Question

Pourquoi utiliser l'un des paquets suivants plutôt que l'autre ?

• Journalisation Java
• Enregistrement des communes
• Log4j
• SLF4j
• Logback

Answer 1

Par ordre chronologique d'apparition de l'api (pour autant que je sache) :

• Log4j parce que la plupart des gens l'utilisent (d'après mon expérience).
• Commons Logging parce que les projets open source l'utilisent (afin de pouvoir s'intégrer avec n'importe quel cadre de journalisation utilisé dans la solution intégrée) ; particulièrement valable si vous êtes un API/Framework/OSS et que vous dépendez d'autres paquets qui utilisent Commons Logging.
• Commons Logging parce que vous ne voulez pas vous "enfermer" dans un cadre de journalisation particulier (vous vous enfermez donc dans ce que Commons Logging vous offre à la place) - je ne pense pas qu'il soit judicieux de décider en utilisant ce point comme raison.
• La journalisation Java parce que vous ne voulez pas ajouter un bocal supplémentaire.
• SLF4j parce qu'il est plus récent que Commons Logging et qu'il fournit une journalisation paramétrée :

---

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback parce qu'il est plus récent que log4j et qu'il prend en charge la journalisation paramétrée, puisqu'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 correspondre quand on regarde leurs précédents messages d'information )
• SLF4j parce qu'ils publient également un adaptateur log4j, ce qui évite d'avoir à "changer" log4j dans un code plus ancien - il suffit de faire en sorte que log4j.properties utilise SLF4j et sa configuration.

Answer 2

Je trouve que la journalisation en Java est confuse, incohérente, mal documentée et surtout désordonnée. De plus, il existe une énorme quantité de similitudes entre ces cadres 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 dans un environnement de journalisation de type multiple (par exemple, hibernate peut utiliser log4j, et tomcat java.util.logging). Apache Commons est censé faire le lien entre les différents cadres de journalisation, mais il ne fait qu'ajouter de la complexité. Si vous ne le savez pas à l'avance, c'est tout à fait déconcertant. Pourquoi mes messages de journal ne s'impriment-ils pas sur la console, etc. Ohh parce que je regarde les logs de Tomcat, et pas ceux de log4j. Ajoutant encore une autre couche de complexité, le serveur d'application peut avoir des configurations globales de journalisation qui peuvent ne pas reconnaître les configurations locales pour une application web particulière. Enfin, tous ces cadres de journalisation sont BEAUCOUP TROP COMPLIQUÉS. La journalisation en Java a été un désordre désorganisé laissant les développeurs comme moi frustrés et confus.

Les premières versions de Java ne disposaient pas d'une structure de journalisation intégrée, ce qui a conduit à ce scénario.

Answer 3

Il y a un point important qui n'a pas été mentionné auparavant :

SLF4J (et Logback et LOG4J en tant que backend de journalisation) prend en charge un contexte de diagnostic mappé (MDC). javadoc y 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 joint à chaque événement.

Cela peut être incroyablement utile si vous y mettez des choses comme le nom d'utilisateur et l'URL de la requête (dans le cas d'une webapp). Cela peut être fait automatiquement en utilisant un filtre, par exemple.

Answer 4

Voir aussi les réponses à la question Quelles sont les meilleures pratiques pour enregistrer une erreur ? surtout :

• Il y a quelques problèmes potentiels problèmes de chargement de classe avec Commons la journalisation.

• Log4J et SLF4J ont été développés par la même personne. la même personne, qui a appris des problèmes rencontrés dans la pratique avec Log4J.

Answer 5

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 doit ressembler votre fichier journal. Il est possible d'améliorer les classes originales de LOG4J.

Toutes les propriétés de LOG4j peuvent être modifiées 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érée, mais c'est peut-être parce que j'utilise log4j depuis le début.