Introduction à SLF4J

1. Vue d'ensemble

Facade de journalisation simple pour Java (abrégé SLF4J) - agit comme une façade pour différents cadres de journalisation (par exemple java.util.logging, logback, Log4j). Il propose une API générique rendant la journalisation indépendante de l'implémentation réelle.

Cela permet à différents cadres de journalisation de coexister. Il aide également à migrer d'un framework à un autre. Enfin, outre l'API standardisée, elle propose également du «sucre syntaxique».

Cet article abordera les dépendances et la configuration nécessaires pour intégrer SLF4J à Log4j2, Logback, Log4J2 et Jakarta Commons Logging. Pour en savoir plus sur chacune de ces implémentations, consultez l'article Introduction à Java Logging.

2. La configuration de Log4j2

Pour utiliser SLF4J avec Log4j2, vous devez ajouter les bibliothèques suivantes à pom.xml :

 org.apache.logging.log4j log4j-api 2.7   org.apache.logging.log4j log4j-core 2.7   org.apache.logging.log4j log4j-slf4j-impl 2.7 

La dernière version peut être trouvée ici: log4j-api, log4j-core, log4j-slf4j-impl.

La configuration de journalisation réelle est conforme à la configuration native de Log4j 2. Voyons comment l' instance Logger est créée:

public class SLF4JExample { private static Logger logger = LoggerFactory.getLogger(SLF4JExample.class); public static void main(String[] args) { logger.debug("Debug log message"); logger.info("Info log message"); logger.error("Error log message"); } }

Notez que Logger et LoggerFactory appartiennent au package org.slf4j . Un exemple de projet, exécuté avec la configuration expliquée, est disponible ici.

3. La configuration de Logback

Pour utiliser SLF4J avec Logback, vous n'avez pas besoin d'ajouter SLF4J à votre chemin de classe. Logback utilise déjà SLF4J. Il est considéré comme l'implémentation de référence. Il suffit d'inclure la bibliothèque Logback:

 ch.qos.logback logback-classic 1.1.7 

La dernière version peut être trouvée ici: logback-classic.

La configuration est spécifique à Logback mais fonctionne de manière transparente avec SLF4J. Avec les dépendances et la configuration appropriées en place, le même code des sections précédentes peut être utilisé pour gérer la journalisation.

4 . La configuration de Log4j

Dans les sections précédentes, nous avons couvert un cas d'utilisation où SLF4J «se trouve» au-dessus de l'implémentation de journalisation particulière. Utilisé comme ça, il fait abstraction complète du cadre sous-jacent.

Il existe des cas où une solution de journalisation existante ne peut pas être remplacée, par exemple en raison d'exigences d'un tiers. Cela ne signifie toutefois pas que le projet est «condamné» uniquement au cadre déjà utilisé.

SLF4J peut être configuré comme un pont, où les appels à un framework existant y sont redirigés. Ajoutons les dépendances nécessaires pour créer un pont pour Log4j:

 org.slf4j log4j-over-slf4j 1.7.30 

Avec la dépendance en place (vérifiez les dernières informations sur log4j-over-slf4j), tous les appels à Log4j seront redirigés vers SLF4J. Consultez la documentation officielle pour en savoir plus sur le pontage des cadres existants.

Tout comme avec les autres frameworks, Log4j peut servir d'implémentation sous-jacente. Ajoutons les dépendances nécessaires:

 org.slf4j slf4j-log4j12 1.7.30   log4j log4j 1.2.17 

La dernière version peut être trouvée ici pour slf4j-log4j12 et log4j. Un exemple de projet, configuré de la manière expliquée est disponible ici.

5. Configuration du pont JCL

Dans les sections précédentes, nous avons montré comment la même base de code peut être utilisée pour prendre en charge la journalisation à l'aide de différentes implémentations. Bien que ce soit la principale promesse et la force de SLF4J, c'est aussi l'objectif derrière JCL (Jakarta Commons Logging ou Apache Commons Logging).

JCL est, de par ses intentions, un framework similaire à SLF4J. La principale différence est que JCL résout l'implémentation sous-jacente pendant le temps d'exécution via un système de chargement de classe. Cette approche est perçue comme problématique dans les cas où des chargeurs de classe personnalisés sont en jeu.

SLF4J résout ses liaisons au moment de la compilation. C'est perçu plus simple mais assez puissant.

Heureusement, deux frameworks peuvent fonctionner ensemble en mode pont:

 org.slf4j jcl-over-slf4j 1.7.30 

La dernière version des dépendances peut être trouvée ici jcl-over-slf4j.

Comme dans les autres cas, la même base de code fonctionnera très bien. Un exemple de projet complet exécutant cette configuration est disponible ici.

6. Plus de bonté SLF4J

SLF4J fournit des informations supplémentaires qui peuvent rendre la journalisation plus efficace et le code plus lisible. Par exemple, SLF4J fournit une interface très utile pour travailler avec des paramètres:

String variable = "Hello John"; logger.debug("Printing variable value: {}", variable);

Voici l'exemple de code de Log4j qui fait la même chose:

String variable = "Hello John"; logger.debug("Printing variable value: " + variable);

Comme vous pouvez le voir, Log4j concaténera les chaînes quel que soit le niveau de débogage activé ou non. Dans les applications à forte charge, cela peut entraîner des problèmes de performances. SLF4J concaténera les chaînes uniquement lorsque le niveau de débogage est activé. Pour faire de même avec Log4J, vous devez ajouter un bloc if supplémentaire qui vérifiera si le niveau de débogage est activé ou non:

String variable = "Hello John"; if (logger.isDebugEnabled()) { logger.debug("Printing variable value: " + variable); }

SLF4J a normalisé les niveaux de journalisation qui sont différents pour les implémentations particulières. Le niveau de journalisation FATAL a été abandonné (il a été introduit dans Log4j) sur la base du principe que dans un cadre de journalisation, nous ne devrions pas décider quand une application doit être arrêtée.

Les niveaux de journalisation utilisés sont ERROR, WARN, INFO, DEBUG, TRACE . Vous pouvez en savoir plus sur leur utilisation dans l'article Introduction à Java Logging.

7. Conclusion

SLF4J facilite la commutation silencieuse entre les cadres de journalisation. Il est simple, mais flexible, et permet d'améliorer la lisibilité et les performances.

Comme d'habitude, le code peut être trouvé sur GitHub. De plus, nous référençons deux autres projets dédiés à différents articles, mais contenant des configurations de journal discutées, ici et ici.