Discussion :

[Baptiste Wicht]

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.

[miaou_]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

mais doit être écrit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[Baptiste Wicht]

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

[miaou_]

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

[Baptiste Wicht]

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

Faut vivre avec son temps

[professeur shadoko]

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

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

[professeur shadoko]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[lunatix]

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

[Baptiste Wicht]

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

Intéressant, merci

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.

[Aldian]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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