Participer au site avec un Tip
Rechercher
 

Améliorations / Corrections

Vous avez des améliorations (ou des corrections) à proposer pour ce document : je vous remerçie par avance de m'en faire part, cela m'aide à améliorer le site.

Emplacement :

Description des améliorations :

Pourquoi utiliser une API de log ?

Utilisation de « Mock objects » Utilisation du package java.util.logging



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 :

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.

on parle de logging en anglais et de journalisation en français pour identifier l'activité de tracé de l'activité de votre application. Vous vous en doutez un peu : je vais continuer à privilégier la terminologie anglaise ;-)

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.

la fondation Apache est très importante dans l'écosystème Java, car elle fournit un très grand nombre de librairies complémentaires, de très bonne facture, au Java SE et à Jakarta EE (ex Java EE).

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.

Liens entre les APIs java.util.logging, Log4J 2 et SLF4J

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).

il existe d'autres API de log comparables à SLF4J et notamment JCL (Java Commons Logging).


Utilisation de « Mock objects » Utilisation du package java.util.logging