Journalisation avec SL4J, journalisation Jakarta Commons, log4j pour les bibliothèques tierces et mon propre code

Question

J'ai quelques questions à propos de la journalisation, plus spécifiquement à propos de son installation et de son fonctionnement.

Le projet que je réalise utilisera Wicket , Spring et Hibernate . Je sais que Wicket et Hibernate utilisent Simple Logging Facade pour Java ( SL4J ) et que Spring utilise le composant de journalisation d'Apache Commons .

Vont-ils coexister avec bonheur? Je pensais utiliser log4j avec SL4J et le composant de journalisation d'Apache commons , pensez-vous que c'est une bonne idée?

Puis-je tous les configurer pour sortir les données de journalisation dans un fichier commun? Ou devrais-je utiliser des fichiers séparés? Ou devrais-je stocker les messages de journalisation dans la base de données? (Je préférerais ne pas le faire, car je trouve Grepping, etc., très pratique sur des fichiers texte.)

Pour Spring, j’ai probablement besoin d’une sorte de fichier de configuration pour le composant de journalisation Apache Commons, dans lequel je le dirige pour qu’il utilise log4j?

Une fois ces éléments configurés, je suppose que pour que tout fonctionne correctement, je règle le niveau de consignation sur INFO, car il est à peu près certain que les trois cadres génèrent des informations dans ce mode. Ou y a-t-il un moyen encore meilleur de s'en assurer?

Et ma dernière question. Dans le projet que je commence, recommandez-vous que j'utilise SL4J pour mes propres besoins de journalisation? (Je pensais utiliser log4j directement, mais c'était avant que j'en apprenne un peu plus sur la journalisation et beaucoup de bibliothèques respectables semblent choisir le chemin d'un pont / façade pour leurs besoins de journalisation. Et si cela nous procure une flexibilité sans ajout coût il n'y a aucune raison de ne pas le faire de cette façon.)

Je suis impatient d’en savoir plus sur la manière dont vous vous connectez. C’est un nouveau domaine dans lequel je suis impatient de progresser.

Answer 1

Eh bien, SLF4J n’est qu’une façade, comme une journalisation commune, ce qui signifie qu’ils ont encore besoin de quelque chose d’autre pour fonctionner. Ils permettent aux auteurs de bibliothèques de ne pas obliger les utilisateurs à avoir plusieurs bibliothèques et configurations de journalisation. Log4j et logback sont des bibliothèques de journalisation classiques.

Voir ici pour plus d'informations.

SLF4J dispose d’un pont de journalisation des communes que vous pouvez utiliser pour remplacer la bibliothèque de journalisation commune. Je pense que le schéma explique très bien la situation.

Maintenant, il vous suffit d'utiliser slf4j-logj12.jar pour que la journalisation des communs et slf4j utilisent log4j (ou tout autre choix de votre part; btw, la consignation n'a pas besoin d'une bibliothèque supplémentaire pour être utilisée avec slf4j) .

Votre application aura donc

• jcl104-over-slf4j.jar (pour connecter la journalisation jakarta commons à slf4j)
• slf4j.jar (pour que hibernate et les autres utilisent slf4j)
• slf4j-logj12.jar (pour que slf4j utilise log4j en tant que backend)
• log4j.jar (à utiliser par votre application. toute la configuration sera également effectuée ici)

Answer 2

Voici comment tout rediriger vers SLF4J:

• supprimez commons-logging.jar de votre chemin de classe. Si vous utilisez Maven et que vous avez des difficultés à vous débarrasser de commons-logging, consultez this .

• mettez jcl-over-slf4j.jar dans votre chemin de classe (il est inclus dans la distribution SLF4J). Il s'agit d'un remplacement instantané imitant les classes de JCL, mais appelant SLF4J en interne. Ceci s’occupera de Spring et de tout autre framework utilisant JCL.

Connectez SLF4J à votre serveur favori (Log4J, Logback ...) en plaçant slf4j-xxx.jar dans le chemin de classe. Configurez le serveur pour consigner toutes les catégories dans un seul fichier, et vous avez terminé.

En ce qui concerne l’utilisation de SLF4J dans votre application, cela n’est pas strictement nécessaire. Des bibliothèques telles que JCL et SLF4J ont été conçues à l’origine pour les personnes qui écrivent des bibliothèques et ne souhaitent pas verrouiller leurs clients dans un cadre de journalisation particulier.

PS: au fait, JCL = Jakarta Commons Logging