Pourquoi utiliser une API de log ?

Accès rapide :
Les difficultés inhérentes au tracé de l'activité de votre programme.
Ce qu'apporte une API de log
Les principales API de log
L'API java.util.logging
L'API Log4J 2
L'API SLF4J (Simple Logging Facade for Java)

Les difficultés inhérentes au tracé de l'activité de votre programme.

Quand vous allez commencer à travailler sur des projets conséquents, vous allez être confronté à une problématique : comment savoir par où vous êtes passé dans votre programme pour arriver à l'état courant ?

Vous pourriez me dire en utilisant un débugger (pourquoi pas celui intégré à Eclipse). C'est effectivement une possibilité, mais ce n'est pas toujours très pratique : faire du pas à pas sur des milliers de lignes de code peut prendre beaucoup de temps.

Vous pourriez aussi me dire en faisant des appels à System.out.println (c'est d'ailleurs ce que nous avons souvent faire jusqu'à présent). Mais la difficulté à tracer l'exécution de l'application avec cette technique, réside dans le fait qu'il est difficile de couper certains affichages et d'en autoriser d'autres en fonction des besoins. Effectivement, il faut systématiquement faire des modifications dans le code, en fonction des besoins.

Nous aurons aussi besoin d'historiser les traces relatives à l'activité de notre programme. Certes, si vous utilisez System.out.println, vous pourrez sans difficulté envoyer ces traces dans un fichier : vous pouvez, par exemple, utiliser une ligne de commande de ce type pour rediriger la sortie du programme vers un fichier log.txt.

$> java StartClassName > log.txt

Mais il ne sera pas aisé d'intégrer automatiquement une information temporelle (ou de séquence) dans les noms de fichiers produits.

Ce qu'apporte une API de log

Je vous conseille très vivement d'utiliser une API de log. Cela permettra justement de répondre aux problématiques que nous venons de soulever. Une API de log permet :

• D'envoyer vos logs à différents endroits et par exemple, sur la console, dans un fichier, dans une base de données, sur un serveur de mail... En les envoyant sur un fichier (souvent, plusieurs formats de fichier sont supportés : texte, XML, JSON...) ou dans une base de données, il devient relativement facile de gérer l'historisation. La plupart du temps, si vous stockez vos logs dans des fichiers, vous pourrez contrôler sous quelle condition on passe au fichier de log suivant (taille maximale atteinte, jour suivant...).

• On peut produire des logs sur différents supports en même temps : assez souvent, on envoie les logs sur la console ainsi que dans un fichier (pour l'historisation).

• Une API de log propose souvent plusieurs niveaux de sévérité pour vos messages : debug, info(rmation), warning ou encore error. Il est possible de demander d'afficher tous les niveaux de log sur la console et d'historiser que les warnings et les erreurs dans un fichier (ou l'inverse, si ça vous est utile).

• Une API de log permet de plus de produire plusieurs « loggers » : pourquoi pas un par composant logiciel ou encore un par classe. Vous pouvez configurer un logger d'un composant pour tracer que les erreurs et un autre pour tracer les messages informatifs, les warnings et les erreurs.

• Une API de log peut se configurer soit par code (non recommandé) soit grâce à un fichier de configuration. Si vous utiliser un fichier de configuration, il devient possible de changer cette configuration sans modifier aucune ligne de code dans votre programme (quelle que soit sa taille).

Vous commencer à en prendre conscience : une API de log est très pratique et elle vous permettra de professionnaliser le tracé de l'exécution de votre programme.

Les principales API de log

Il existe, en Java, plusieurs APIs de log (ou APIs de logging) : toutes les présenter nous prendrait beaucoup trop de temps. Je préfère me limiter à trois API majeures dans l'histoire de Java. Elles seront étudiées plus en détails dans les prochains chapitres de ce tutoriel.

L'API java.util.logging

La première API de log que je vous présente n'est pas la plus ancienne (c'est Log4J de la fondation Apache que est apparue en première). Nous allons l'appeler JUL (pour java.util.logging). Vous l'aurez compris, grâce au nom du package qui la contient, cette API est proposée de base par le Java SE et ce depuis sa version 1.4. C'est ce point qui m'amène à vous la présenter en première.

Comme elle fait partie du Java SE, vous n'avez donc aucun JAR complémentaire à télécharger.

L'API Log4J 2

Log4J est une API de log proposée par la fondation Apache et vous pouvez trouver ce logiciel sur son site officiel : http://logging.apache.org/log4j/2.x/ Le nom Log4J signifie Logging for Java.

Attention, historiquement parlant, il y a eut deux APIs de logging appelées Log4J. La première fut développée par la fondation Apache à partir de 2001. Cette version est maintenant abandonnée au profit de Log4J 2 : il s'agit d'une réécriture complète du moteur de log. Il n'y a donc aucune compatibilité entre les deux versions et la migration d'une version à l'autre nécessitera des modifications dans le code.

Comme l'API Log4J (première du nom) est apparue bien avant l'API JUL (java.util.logging), elle a été massivement utilisée. Lors du passage à Log4J 2, les utilisateurs historiques ont basculé sur cette nouvelle implémentation au détriment de JUL.

Vous pouvez télécharger Log4J 2 à partir du site https://logging.apache.org/log4j/2.x.

L'API SLF4J (Simple Logging Facade for Java)

La dernière API dont je souhaite vous parler, n'est pas une API de log à proprement parler. Il s'agit plutôt d'une surcouche d'abstraction permettant à votre application de fonctionner avec une API de log quelconque. Ainsi le changement de la solution de log concrétement utilisée, n'impactera aucune ligne de code de votre application.

Pour comprendre son intérêt, imaginons le scénario suivant : vous développez une application Web en Java pour la gestion du personnel d'une entreprise. Pour fonctionner, cette application aura donc besoin d'un serveur Web compatible Jakarta EE (anciennement Java EE). De plus, vous souhaitez vendre l'application sans imposer à vos clients le choix d'un serveur Web. Or, les serveurs Web utilisent déjà une API de log : par exemple Tomcat utilise JUL (java.util.logging) alors que d'autres utilisent Log4J ou autre. Du coup, comment garantir que notre application tracera correctement l'activité de l'application quelle que soit l'API concrètement utilisée par le serveur Web ?

Vous l'avez compris, oui SLF4J sera dans ce cas une bonne solution : il ré-routera les demandes de log sur l'API sous-jacente. Grace à SLF4J on peut donc être complément indépendant de la solution de log retenue. Le contre-coup, c'est qu'on utilise un sur-couche, ce qui ralentit un peu les performances (mais ça peut être négligeable).