Une réunion de l’équipe est organisée avec toute l’équipe : Jenny, Marc, Juan et vous. Les retours exprimés sont les suivants :
Jenny :
Je suis vraiment contente des résultats obtenus jusque-là !
Juan :
Je ne rencontre pas de dysfonctionnement, ce qui est très positif. Je profite de cette réunion pour une requête : serait-il possible d’avoir des traces de ce qu’il se passe lors de l’exécution ? Cela m’aiderait à analyser le comportement de l’application lorsque je détecte un dysfonctionnement.
Marc :
Tu as absolument raison Juan, côté développement cela nous aiderait également à corriger de potentiels dysfonctionnements à venir. Nous allons nous y mettre de ce pas !
La réunion terminée, Marc vous lance sur le thème de la journalisation, en anglais Logging.
Laissez des traces grâce au Logging
Une trace ou un log en anglais est une information issue de l’exécution du code de l’application.
Pourquoi vouloir laisser des traces ? Nous accédons au code après tout.
C’est vrai, mais il arrive qu’à l'exécution le code se comporte d’une façon que nous n’avions pas imaginé et dans ces moments savoir plus précisément ce qu’il s’est passé sera salvateur !
Nous avons notre objectif : laisser des traces !
Mais où ?
Plusieurs possibilités s’offrent à nous. La plus facile est de les laisser dans la console. D’autres sont plus pertinentes comme, par exemple, les écrire dans un fichier ou encore mieux dans une base de données.
Pour l’instant nous nous contenterons d’écrire dans la console.
Quelles traces allons-nous laisser ?
Cela dépend des besoins de ceux qui vont les consulter. Si je suis un testeur, comme Juan, je vais surtout être intéressé par des traces qui concernent les erreurs. Si je suis développeur et que je dois investiguer, j’aimerais certainement des traces précises concernant le code dysfonctionnel. Si je suis un utilisateur, j’aimerais certainement ne pas voir de traces !
Autrement dit, nous ne pouvons nous contenter d’une seule approche et il faudra donc une stratégie de logging. Pour répondre à cette problématique, en Java les bibliothèques de logging offrent des niveaux de logs.
Le concept consiste en l’association d’une trace avec un niveau. Ensuite lors de l’exécution de l’application le niveau de log à utiliser est défini. Toutes les traces associées à ce niveau et au niveau supérieur sont utilisées.
Voici un exemple de niveaux de log :
Nom du niveau | Valeur du niveau |
OFF | 0 |
FATAL | 100 |
ERROR | 200 |
WARN | 300 |
INFO | 400 |
DEBUG | 500 |
TRACE | 600 |
ALL | Integer.MAX_VALUE |
Le niveau OFF sera donc celui à appliquer pour les utilisateurs finaux où nous ne voulons voir aucune trace.
Le niveau ALL est son extrême opposé, il est le plus verbeux et affiche la moindre trace disponible !
La valeur du niveau permet de les classer. Cela permet également de créer des niveaux personnalisés et d’y affecter une valeur numérique en fonction de la position que nous souhaitons donner dans cette hiérarchie.
Pouvez-vous nous montrer comment faire ?
Absolument et pour cela nous utiliserons Log4J !
Découvrez Log4J, la bibliothèque de Logging la plus répandue
Apache Log4J est la bibliothèque logging la plus répandue dans l’univers Java. Et l’univers Java est l’un des plus répandus dans le monde de la programmation logiciel !
Vous n'exagérez pas un peu ?
Je vois que vous voulez une preuve ! Avez-vous entendu parler de la vulnérabilité CVE-2021-44228 ? En décembre 2021, une secousse ébranle le monde à la suite de la découverte d’une faille de sécurité dans la bibliothèque Log4J. Si les détails de la vulnérabilité ne nous intéressent pas ici, les réactions observées ont révélé à quel point cette bibliothèque est utilisée dans des milliers de systèmes. Bien évidemment cette vulnérabilité est aujourd’hui corrigée. Je trouve toujours très pertinent de mentionner cette anecdote à mes étudiants comme preuve de l’omniprésence du Java et de Log4J.
Il existe bien évidemment d’autres bibliothèques. Java offre même une solution native nommée API Logging. Une autre bibliothèque réputée est LogBack.
Allez, passons à la pratique avec Log4J !
Mettez en œuvre Log4J
Dans la démonstration suivante je vous montre tout d’abord comment mettre en place la librairie log4j dans un projet :
Le point clé de la démonstration à retenir est que la bibliothèque Log4J doit être téléchargée et les fichiers jar sont ajoutés au projet.
Maintenant voyons dans la démonstration suivante comment utiliser la librairie log4j :
Les points à retenir sont les suivants :
Il faut configurer Log4J avec un fichier de propriétés log4j2.properties.
Pour écrire une trace nous utilisons une instance de org.apache.logging.log4j.Logger
Chaque niveau de trace à sa méthode associée, par exemple
logger.info(“ma trace…”);
La configuration utilisée est la suivante :
log4j2.properties
rootLogger = ERROR, STDOUT
loggers = ej.blocs
logger.ej.blocs.name = ej.blocs
logger.ej.blocs.level = INFO
appender.console.name = STDOUT
appender.console.type = Console
appender.console.layout.type = PatternLayout
appender.console.layout.pattern = [%-5level] %d{yyyy-MM-dd HH:mm:ss.SSS} [%t] %c{1} - %msg%nEn résumé :
Nous avons utilisé un appender qui écrit dans la console.
Le niveau de log est défini sur INFO pour les classes dans le package ej.blocs pour les autres classes ce sera ERROR.
Le pattern permet de définir ce qui sera affiché dans la trace en plus du message choisi par le développeur (par exemple la date).
Pour récupérer une instance de la classe Logger nous utilisons le code suivant :
private static Logger logger = LogManager.getLogger(Main.class); où le paramètre Main.class doit être substitué par la classe concernée par le Logger.
Et cela s’arrête là ?
En effet, utiliser un logger est assez simple ! Ce qui peut être compliqué :
Configurer la bibliothèque avec d’autres appenders pour écrire dans un fichier, une base de données ou autres.
Choisir les traces à écrire au fur et à mesure de l’implémentation du programme.
Voici quelques bonnes pratiques :
Chaque classe doit avoir sa propre instance de Logger.
Les traces doivent être datées.
Les niveaux de logs doivent être définis en fonction des packages.
Les traces ne doivent pas polluer l’utilisateur final.
La configuration du logging doit être externalisée dans un fichier pour pouvoir la modifier à chaud sans avoir à redémarrer l’application.
Aucune information sensible (comme un mot de passe) ne doit être dans les traces.
A vous de jouer
Contexte
Marc vient de définir la stratégie à adopter, voici ce qu’il souhaite mettre en place :
Niveau de log | Mise en oeuvre |
ERROR | Dès qu’une exception est attrapée, une trace au niveau ERROR doit être écrite avec un message adapté à l’erreur rencontrée. |
INFO | La construction d’un bloc doit déclencher l’écriture d’une trace au niveau INFO. La trace doit indiquer le type de bloc construit. |
C’est un démarrage en douceur ! La configuration de Log4J doit être réglée sur le niveau ERROR pour le rootLogger et INFO pour le package ej.blocs.
Consignes
Regrouper l’interface IBloc, les classes Bloc, Mur, Porte et l'énumération Couleur dans un package ej.blocs.
Ajouter les jars log4j-api-2.XX.jar et log4j-core-2.XX.jar dans le projet.
Configurer le logging avec un fichier log4j2.properties.
Ajouter les traces selon ce qui a été demandé par Marc.
En résumé
Le logging est essentiel pour obtenir des programmes de qualité.
Plusieurs bibliothèques permettent de faire du logging dont l’API Logging native à Java, Log4J ou encore LogBack.
La configuration permet de définir le niveau de log à appliquer au programme et la façon dont les traces sont écrites.
Une stratégie de logging doit être appliquée sur tout le code de façon homogène.
Dans le prochain chapitre nous aborderons la question des flux en Java via la manipulation de la console et de fichiers.
