Quoi de neuf avec la journalisation en Java? [fermé]

Pourquoi l'un utiliserait l'un des packages suivants au lieu de l'autre?

• Journalisation Java
• Journalisation Commons
• Log4j
• SLF4j
• Se connecter

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 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 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

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.

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.

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.

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).

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à.

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.