Journalisation Java vs Log4J [fermé]

134

Vaut-il toujours la peine d'ajouter la bibliothèque log4j à un projet Java 5 juste pour enregistrer, disons, quelques exceptions à un fichier avec de jolis paramètres de survol. Ou la fonction standard util.logging fera-t-elle également l'affaire?

Qu'est-ce que tu penses?

— Okami
source

Voir stackoverflow.com/a/13144054/603516 pour de nombreux problèmes de verrouillage de log4j 1.2 à prendre en compte.

— Vadzim

115

Je dirais que vous êtes probablement d'accord avec util.logging pour les besoins que vous décrivez.

Pour un bon arbre de décision, jetez un œil à Log4j vs java.util.logging

Première question: prévoyez-vous un besoin pour l'un des gestionnaires intelligents que Log4j a que JUL n'a pas, tels que SMTPHandler, NTEventLogHandler ou l'un des FileHandler très pratiques?

Deuxième question: Voyez-vous vouloir changer fréquemment le format de votre sortie de journalisation? Aurez-vous besoin d'un moyen simple et flexible de le faire? En d'autres termes, avez-vous besoin du PatternLayout de Log4j?

Troisième question: prévoyez-vous un besoin certain de pouvoir modifier des configurations de journalisation complexes dans vos applications, après leur compilation et leur déploiement dans un environnement de production? Votre configuration ressemble-t-elle à quelque chose comme: «Les messages graves de cette classe sont envoyés par courrier électronique au support technique; les messages graves d'un sous-ensemble de classes sont enregistrés dans un démon syslog sur notre serveur; les messages d'avertissement d'un autre sous-ensemble de classes sont enregistrés à un fichier sur le lecteur réseau A; puis tous les messages de partout sont enregistrés dans un fichier sur le lecteur réseau B "? Et vous voyez-vous le peaufiner tous les deux jours?

Si vous pouvez répondre oui à l'une des questions ci-dessus, utilisez Log4j. Si vous répondez par un non catégorique à tous, JUL sera plus que suffisant et il est déjà inclus dans le SDK.

Cela dit, à peu près tous les projets de nos jours semblent finir par inclure log4j, ne serait-ce que parce qu'une autre bibliothèque l'utilise.

— Matt Sheppard
source

1

Excellente réponse basée sur un questionnaire. A chacun son propre en fonction des besoins.

— HopeKing

43

Je vous recommande d'utiliser la façade de journalisation simple pour Java (SLF4J). Il prend en charge différents fournisseurs qui incluent Log4J et peut être utilisé en remplacement de Apache Commons Logging.

— Brian Matthews
source

6

Quel est le problème avec la journalisation Commons?

— Bart van Heukelom

5

@Bart van Heukelom et commenter les votants positifs - lire articles.qos.ch/thinkAgain.html

— Stephen C

4

@Stephen C: Merci pour l'info, même si j'ai appris cela il y a quelque temps et que j'utilise maintenant SLF4J chaque fois que je le peux. (Mon commentaire était une vraie question btw, pas une remarque conservatrice)

— Bart van Heukelom

1

@Bart, Commons Logging utilise la découverte dynamique du package à utiliser. L'utilisation de SLF4J (ou utilisée pour) nécessite que les classes du backend se chargent du tout.

— Thorbjørn Ravn Andersen

21

Log4j existe depuis longtemps et cela fonctionne très bien. Je n'ai aucune étude scientifique pour le soutenir, mais sur la base de ce que j'ai vu chez un grand nombre de clients, c'est facilement le cadre de journalisation que je vois utilisé plus que tout autre. Il existe depuis longtemps et n'a pas été remplacé par le Next Big Logging Framework, qui dit quelque chose.

Il est extrêmement simple à mettre en place et facile à apprendre les appenders (sorties) de base. Il existe de nombreux ajouts d'hôte disponibles, notamment:

ConsoleAppender
DailyRollingFileAppender
ExternallyRolledFileAppender
FileAppender
JDBCAppender
JMSAppender
NTEventLogAppender
RollingFileAppender
SMTPAppender
SocketAppender
SyslogAppender
TelnetAppender
WriterAppender

Plus d'autres. Il n'est pas non plus difficile d'écrire votre propre appender. De plus, il existe une grande flexibilité dans chacun des ajouteurs qui vous permet de contrôler spécifiquement ce qui est sorti dans votre journal.

Une note, j'ai eu une série de problèmes de chargeur de classe lorsque j'ai utilisé la journalisation apache commons en plus de log4j. Ce n'était que pour une application spécifique, mais j'ai trouvé plus simple d'utiliser log4j seul, plutôt que d'avoir la flexibilité offerte lors de l'utilisation d'une couche d'abstraction comme la journalisation des communs.

Consultez cet article pour plus de détails :

Bonne chance!

— Rydell
source

17

java.util.logging offre un package de journalisation complet sans l'excédent de bagages que certains autres fournissent.

— Adam
source

5

De plus, il est inclus par défaut et utilisé par Java lui-même (donc vous l'aurez quand même!)

— A QUITTER - Anony-Mousse

7

log4j est un package beaucoup plus agréable dans l'ensemble, et n'a pas certains des problèmes que contient java.util.logging. Je dirais que l'utilisation directe de log4j est plus facile que l'utilisation de la journalisation des communs.

— Will Sargent
source

3

Pouvez-vous être plus précis sur le hoquet de java.util.logging?

— alkber

Bien sûr, comme la surcharge dans la journalisation des méthodes synchronisées: voir github.com/playframework/playframework/issues/6958 et bugs.openjdk.java.net/browse/JDK-8077846

— Will Sargent

4

Je recommande d'utiliser Apache Commmons Logging comme interface de journalisation. De cette façon, vous avez la possibilité de changer d'implémentation de journalisation à tout moment sans nécessiter de changement de code de votre part.

— Edmund Tay
source

3

J'irais avec log4j. Les possibilités avec log4j ne sont pas du tout obsolètes!

— svrist
source