Apache Common Logging et Log4J en Java

Le Java fournit nativement une librairie de gestion de log. Cette librairie permet une gestion assez précise des logs, elle n’est pas forcément facile à mettre en place. En effet, il faut paramétrer manuellement les loggers parents pour pouvoir avoir une utilisation fluide des loggers fils. Afin de simplifier tous ces traitements, la fondation Apache a créé à travers le projet Jakarta plusieurs API permettant la gestion des logs. Apache Commons Logging et Apache Log4J se couplent parfaitement pour alléger le traitement du logging et en simplifier l’utilisation pour les développeurs.

javajakartalog4j

Apache Commons Logging (projet Jakarta)

L’Apache Commons Logging est une couche d’interfaces légère et performante qui a pour objectifs d’être facile à utiliser et très rapide à mettre en place. En effet, l’ACL est une couche d’abstraction qui va se baser sur une API de Logging. Son utilisation généraliste permet aux développeurs de rédiger leur code, et d’avoir juste à charger l’API de Logging qu’ils veulent voir utilisée. Les API utilisables sont LOG4J, Avalon LogKit, JDK 1.4 et une implémentation de l’API de logging JDK 1.4 pour les systèmes d’avant la JDK 1.4.

Les principaux objets de l’ACL sont le Log et la LogFactory. Le Log est la classe qui va réaliser les actions de logs avec plusieurs méthodes courantes. La LogFactory est l’objet qui va aller chercher l’implémentation sous-jacente choisie par le développeur. L’objet va parcourir ces différentes étapes jusqu’à trouver l’implémentation identifiée.

  1. Attribut de configuration org.apache.commons.logging.Log présent dans le code Java ou dans un fichier de properties, commons-logging.properties présent dans le classpath.
  2. La propriété système org.apache.commons.logging.Log.
  3. API de logging Log4J et utilisations du Log4JLogger.
  4. Si utilisé sur JDK 1.4 ou plus, utilisation du JDK 1.4Logger.
  5. Utilisations de la class SimpleLog de l’ACL.

Log4J

Log4J est un projet open-sources de Logging Java. Son utilisation est semblable à celle de l’API native de Java, mais il est plus facilement paramétrable. Il utilise trois composants principaux :

  • Appenders : ce sont des classes qui vont déterminer le type de sortie, l’endroit où seront inscrits les logs.
  • Logger : ce sont objets qui vont réaliser l’action de log et auxquels nous associons un niveau de log et un Appender pour définir leur comportement.
  • Layout qui définissent la manière dont les logs sont présentés

Log4J est très utilisé car il est très facile à mettre en place. Sa configuration se fait via un fichier de configuration .properties ou XML. Il utilise le même système de hiérarchie que l’API de logging Java native, les noms des objets Logger sont classés hiérarchiquement et chaque fils reçoit par défaut la configuration de son père, et fait appel à lui s’il est utilisé. Les temps de traitements sont optimisés afin de ne pas déranger le déroulement normal de l’application.

Mise en place

log4j.xml

Afin de pouvoir utiliser ce couple d’API, il faut importer les jars correspondant sur les sites suivants: ACL et Log4J. Ou si vous utilisez Maven :

Nous allons maintenant mettre en place une configuration Log4J afin de pouvoir l’utiliser avec l’Apache Commons Logging. Je vais décrire ici une configuration sous forme de XML qui selon moi est plus claire même si ce n’est pas la plus documentée sur Internet. De nombreux tutoriels présentent le format properties qui est très proche.

Tout d’abord, nous définissons le fichier log4j.xml comme un fichier xml de configuration:

Notre fichier créé, nous allons y paramétrer un Appender qui aura pour but d’inscrire les logs en Console.

Cet Appender, définit par le nom « console », est lié à la classe « org.apache.log4j.ConsoleAppender », l’affichage se fait sur la sortie Console standard « System.out ». Il est également possible de cibler la sortie Console d’erreur : « System.err ». Le layout affiche le niveau de log, la classe qui appelle le Logger et le message défini.

Ensuite, nous définissons le Logger principal ou racine de notre application.

Ce Logger principal utilise l’Appender défini plus tôt et affichera les messages qui ont pour niveau DEBUG, INFO, WARNING, ERROR et FATAL.

Ainsi, on obtient le fichier de configuration log4j.xml

Output:

Les Loggers génèrent souvent un fichier qui est consultable pour les opérations de maintenance et de suivi de l’application. L’Appender suivant va gérer ce cas de figure avec le logger correspondant.

On retrouve la même structure avec des données supplémentaires pour configurer le logger. La classe RollingFileAppender permet l’envoi des messages dans un fichier jusqu’à ce qu’il atteigne une certaine taille. Le paramètre Append indique au logger qu’il doit ajouter au fichier de log et non pas le remplacer. Le paramètre MaxFileSize indique à partir de quelle taille le logger doit créer un nouveau fichier de log. Et enfin le paramètre MaxBackupIndex définit le nombre maximum de fichiers de logs à conserver. Le Logger se voit attribuer un nom. Ainsi tous les sous-packages correspondant à ce nom se verront attribuer ce Logger-Père et leurs Loggers seront ses fils.

Output dans le fichier :

Les autres classes Appenders sont listées ci-dessous (non exhaustif):

  • AsyncAppender : vers différents appenders de façon périodique et asynchrone
  • ExternalyRolledFileAppender : sur un fichier à rotation à la réception d’un message dédié sur une socket et envoi d’un accusé de traitement
  • JMSAppender : vers une destination utilisant JMS
  • LF5Appender : sur une application Swing dédiée
  • NullAppender : messages ignorés
  • SMTPAppender : par mail
  • SocketAppender : dans une socket
  • SocketHubAppender : ans plusieurs sockets
  • TelnetAppender : dans une socket en lecture seule facilement consultable avec l’outil telnet
  • ConsoleAppender : sur la console
  • FileAppender : dans un fichier. Possède deux classes filles : DailyRollingAppender et RollingFileAppender
  • DailyRollingFileAppender : dans un fichier à rotation périodique (pas obligatoirement journalière)
  • RollingFileAppender : dans un fichier à rotation selon sa taille
Toto.java (utilisation de l’ACL)

Pour utiliser cette configuration nous allons créer un Log dans notre classe Toto. La LogFactory va fournir une instance de la classe Log en se basant sur l’implémentation sous-jacente sans que nous ayons à lui indiquer.

Il est commun de mettre ce type d’attribut en privé et static afin qu’il soit facilement accessible de l’intérieur de la classe, et non dépendant de l’instance de la classe. De nombreuses méthodes dans la classe Log permettent de réaliser une action de log avec différents niveaux.

 

Conclusion

Ces APIs ont un fonctionnement proche de l’API native de Java, si vous souhaitez avoir plus de détails sur cette dernière, rendez vous sur cet article.

Ce couple d’API permet la simplification du paramétrage de logging de nos applications. Il est très facile à mettre en place via un fichier externe et les possibilités sont nombreuses. J’utilise personnellement ces outils sur des applications Web en Java, car ils ne sont pas intrusifs et ne gênent ni mon développement ni l’exécution de l’application tout en procurant des logs nécessaires aux applications.

Plus de détails sont disponibles à cette adresse.

 

spacer

Laisser un commentaire