Journalisation avec SLF4J

Bonjour,

Je viens d'écrire un nouvel article : Journalisation avec SLF4J

Cet article va vous montrer comment utiliser SLF4J dans votre projet. SLF4J est une couche d'abstraction de journalisation à l'image de Commons Logging, mais avec plusieurs avantages par rapport à ce dernier. Ces avantages sont tous décrits dans l'article ainsi que les différentes fonctionnalités de cette librairie.

J'espère que cet article vous intéressera.

Joli article, clair et précis.

J'ai juste noté un point, sur l'exemple des messages paramétrés (des plus pratiques une fois qu'on y a pris goût :)).
De mon souvenir (en tout cas avec la version 1.5.10) le code suivant n'est pas valable :

Code:

---

logger.debug("Info : x = {}, y = {}, str = {}", info.getX(), info.getY(), infos.getStr());

---

mais doit être écrit

Code:

---

logger.debug("Info : x = {}, y = {}, str = {}", new Object[] { info.getX(), info.getY(), infos.getStr() });

---

cf. FAQ slf4j.

Comme tu l'ajoutes dans ta conclusion, je confirme que l'utilisation de l'implémentation logBack est un bon choix. En tout cas, aucun problème à signaler sur nos projets. (Pour rappel, logback est une refonte/ré-écriture de log4j par le créateur de celui-ci).

Encore bravo pour l'article.
Nicolas.

Erf, comme deux arguments marchaient, j'étais sûr qu'ils utilisaient des varargs... Je me demande bien pourquoi il ne les utilise pas d'ailleurs :?

Merci de me l'avoir fait remarqué, je vais regarder ça dès que possible :ccool:

pas de varargs... probablement que slf4j reste compatible java 1.4.
à vérifier :)

Citation:

---

Envoyé par miaou_

pas de varargs... probablement que slf4j reste compatible java 1.4.
à vérifier :)

---

Faut vivre avec son temps :)

un petit détail me chagrine: LoggerFactory n'est pas clair, clair en ce qui concerne la notion de Logger rattaché à un package.
petite explication: perso le package est pour moi l'unité fondamentale d'un contexte de logging (oui je sais certains font ça au niveau d'une classe ... mais j'en vois pas l'intérêt au niveau d'un principe général).
Adoncques: on peut certes utiliser une chaine pour donner un nom, mais j'aurais préféré quequechose du style getLoggerForPackage(un objet simple).
note: j'ignore tout de Log4j (donc ma remarque attend toute correction utile).

Effectivement, ce pourrait être quelque chose de pratique pour ceux qui comme dans ton cas font de la journalisation au niveau package, mais je ne connais aucun framework de journalisation qui le fait. A ma connaissance, ni JUL, ni JCL, ni Log4J, ni SLF4J ni LogBack ne le font.

Tu utilises quoi comme outil de journalisation généralement ?

A noter quand même que ce n'est pas très difficile d'obtenir un logger pour un package en créant une petit classe utilitaire et une méthode statique getLogger(Package package) ou/et getLoggerForPackage(Class aClass).

Citation:

---

Envoyé par Baptiste Wicht

Effectivement, ce pourrait être quelque chose de pratique pour ceux qui comme dans ton cas font de la journalisation au niveau package, mais je ne connais aucun framework de journalisation qui le fait. A ma connaissance, ni JUL, ni JCL, ni Log4J, ni SLF4J ni LogBack ne le font.

Tu utilises quoi comme outil de journalisation généralement ?

A noter quand même que ce n'est pas très difficile d'obtenir un logger pour un package en créant une petit classe utilitaire et une méthode statique getLogger(Package package) ou/et getLoggerForPackage(Class aClass).

---

j'utilise java.util.logging .... et effectivement mon getLogger est un peu particulier (en fait c'est toujours la même expression qui est calculée statiquement au niveau d'une classe standard du package de nom PackCST qui contient tout ce qui concerne le package courant).
De mémoire ça donne un truc qui ressemble à :

Code:

---

1 2 3 4 5 6

class PackCst { // non public static final Logger CURLOG = Logger.getLogger( PackCst.class.getPackage().getName()) ; // autres inits statiques (ressources, etc....) }

---

certes ça fait un tas d'init statiques ... mais bof....

pour ce qui est des varargs, je vous laisse lire le debat http://bugzilla.slf4j.org/show_bug.cgi?id=31

Citation:

---

Envoyé par lunatix

pour ce qui est des varargs, je vous laisse lire le debat http://bugzilla.slf4j.org/show_bug.cgi?id=31

---

Intéressant, merci :ccool:

Par contre, je trouve dommage que des projets continuent à refuser des changements pour la compatibilité avec une vieille version de Java. la version 1.4.2 a tout de même 2 versions de retards. La version 1.4.2 a tout de même 8 ans et est en EOSL depuis 2 ans.

Salut je me demande s'il n'y a pas une erreur dans le paragraphe suivant:

Code:

---

Vous me direz : si Commons Logging fait déjà cela, pourquoi un autre framework d'abstraction de logging ? Tout simplement parce que Commons Logging a ses défauts. Le premier gros défaut de Commons Logging concerne le chargement de l'implémentation de journalisation. En effet, la recherche de l'implémentation se fait dynamiquement à l'implémentation via un système de classloader. Or cette méthode peut poser problèmes dans certaines situations, par exemple lorsque l'application utilise des classloaders personnalisés ou alors au sein d'une architecture OSGi. De plus, l'implémentation utilisée par Commons Logging peut causer des fuites mémoires.

---

Code:

---

1 2 3 4 5 6

En effet, la recherche de l'implémentation se fait dynamiquement à l'implémentation => En effet, la recherche de l'implémentation se fait dynamiquement au runtime

---

A part ça bravo pour ce tutoriel très clair et très intéressant. Le seul point que je regretterai, c'est qu'il donne tous les avantages de SLF4J par rapport à commons-logging, mais ne donne aucun de ses inconvénients, et pourtant il doit bien y en avoir...