Slf4j + Logback : pourquoi tout le monde devrait migrer

De nombreux projets continuent à s’appuyer sur log4j, avec bien souvent une surcouche de commons-logging (JCL). Certes, ils constituent des grands standards historiques, mais il serait grand temps de migrer!

La couche d’abstraction : commons-logging vs slf4j

Les problèmes de classloader

JCL pose de nombreux problèmes de classloader car le bind avec l’implémentation de log se fait au runtime. Inutile de faire du OSGI pour avoir de gros soucis, il suffit de redémarrer son application sans redémarrer toute la JVM (ce que tout le monde fait en développement) pour rencontrer des fuites de classloader! Slf4j travaille de manière beaucoup plus propre et effectue son binding à la compilation. A titre d’exemple, voici ce que pense Springsource.

Une API plus propre

Tout d’abord, finis les “logger” qui s’appellent Log et les “fabriques de logger” qui s’appellent LogFactory…
Plus important, par exemple, l’API construit elle-même les messages en effectuant de l’interpolation. Exit donc les tests “if LOGGER.isDebugEnabled()” qui polluent le code, vous n’avez qu’à faire :

1
LOGGER.debug("mon message : {}", mon paramètre);

L’implémentation : log4j vs logback

La maintenance

Logback est en fait le descendant naturel de log4j; le projet a été monté par le fondateur historique de log4j après son départ. Il s’agit de l’implémentation par défaut de slf4j-api. L’activité de maintenance sur log4j est quasi nulle.

De meilleures performances et quelques fonctionnalités sympas

Vous trouverez une liste exhaustive des raisons de migrer de log4j vers logback ici.
A titre d’exemple, on peut citer le rechargement à chaud automatique du fichier de conf. Certains utilisateurs rencontrent des problèmes en prod? Pas de problème, vous abaissez temporairement le niveau de certains logger, sans avoir à redémarrer toute l’application et déconnecter tous vos utilisateurs! Elle est pas belle, la vie?

En pratique, comment ça se passe?

  1. Vous virez commons-logging! Si vous êtes sous maven, inutile de vous tapez des exclusions sur toutes vos librairies tirant jcl (ex: tous les modules spring…). Un petit malin a trouvé l’astuce suivante : déployer une librairie vide avec une version bidon qu’on forcera dans le dependencyManagement.
  2. Rediriger les “loggers” de toutes les API de log utilisées par vos librairies legacy vers slf4j à l’aide des bridges XXX-to-slf4j (jcl, log4j, JUL…).
  3. Fournir une implémentation (et une seule!) de slf4j-api. Si vous avez suivi, il vaut mieux utiliser logback, mais si vous tenez absolument à votre API legacy (parce que par exemple vous avez développé des customisations s’appuyant sur des classes internes…), vous pouvez le faire tout simplement en collant un bridge du type slf4j-to-XXX.
VN:R_U [1.9.22_1171]
Rating: 0 (from 0 votes)
Share
Ce contenu a été publié dans Non classé, avec comme mot(s)-clef(s) , . Vous pouvez le mettre en favoris avec ce permalien.

4 réponses à Slf4j + Logback : pourquoi tout le monde devrait migrer

  1. Tiens, une ptite question que jme pose : dans ton exemple de code, tu sembles privilégier l’utilisation d’un logger statique (“LOGGER”).

    Dans l’exemple du manuel SLF4J, ils utilisent un logger par instance.

    
    
    1
    2
    3
    public class Wombat {
      final Logger logger = LoggerFactory.getLogger(Wombat.class);
    }

    Des arguments pour privilégier une approche plutôt que l’autre ?

    Sinon, sur l’utilisation de “logger” plutôt que “log”, ça ressemble fortement à une querelle de clocher. “ça a plus de sens” vs “c’est plus court à taper” :-)

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
    • static vs par instance : nope, pas de préférence particulière, sachant que l’implem (en tous cas logback) garde bien évidemment un cache. Même le final est discutable si vous voulez injecter votre Logger (ça fera l’objet d’un autre post).

      logger vs log : disons que c’était une référence au niveau du débat qui a fait rage (et oui…) à l’époque à l’apparition de jcl (bouhouhou, chuis vieux…). Mais les classes n’ont pas été nommées à l’époque dans un soucis de concision, mais simplement mal nommées. Certains framework de log utilisent d pour debug, i pour info, etc… Bon, on n’est plus au temps du C, on a des IDE avec une autocomplétion performante qui nous permet d’écrire du code lisible sans trop se fouler…

      VN:R_U [1.9.22_1171]
      Rating: 0 (from 0 votes)
  2. Petit complément de réponse : voici ce que dit la doc officielle à ce sujet.

    VN:R_U [1.9.22_1171]
    Rating: 0 (from 0 votes)
  3. Ping : Gestion des logs en Java « Le blog de Guillaume Husta

Laisser un commentaire