Commons-logging VS SLF4J

Commons-logging

Jakarta Commons-logging (JCL) est une couche d’abstraction permettant d’utiliser n’importe quel mécanisme de log (java.util.logging, log4j) sans utiliser directement leur implémentation. Cela permet donc de changer de framework de log sans impacter toute l’application. Seulement, change-t-on vraiment de framework de log tous les quatre matins ? On utilise généralement log4j, qui est très complet et fait très bien ce qu’il a à faire et jamais on n’en change !

Surconception
Petit aparté sur la surconception. On a souvent tendance à mettre en place des couches d’abstraction « au cas où ». JCL au cas où on changerait de framework de log, des interfaces à tout va au cas où on ajouterait une nouvelle implémentation, la séparation jar/war au cas où on ferait une nouvelle IHM…
Ne pourrait-on pas se contenter du nécessaire et abstraire le jour où on en aura vraiment besoin ?
Pour ceux qui ne connaissent pas le Test Driven Development (TDD), voilà les règles que la méthode énonce :

• On écrit le(s) test(s) qui vérifie(nt) la fonctionnalité (et qui échoue vu que la fonctionnalité n’est pas encore implémentée).
• On écrit le code le plus simple possible qui fait passer le test. Pas de superflu, juste le nécessaire !
• On itère sur les deux étapes précédentes pour ajouter d’autres fonctionnalités.
• On refactor le code lorsque cela devient nécessaire. C’est à ce moment que l’on se pose la question des interfaces, des couches d’abstractions…

A quoi bon utiliser JCL alors ? Il y a des cas où vous ne pourrez y échapper, par exemple si vous développez non pas une application mais un framework ou une api qui sera utilisée par des applications. Effectivement, dans de tels cas, vous ne savez pas quel framework de log est utilisé et vous ne pouvez imposer log4j par exemple si le projet qui utilise votre framework/api fait du java.util.logging.

L’utilisation de JCL m’a posé pas mal de problème sur WAS et aux vues des nombreuses plaintes à ce sujet, je ne pense pas être le seul. Effectivement, WAS embarque sa propre version de JCL et gère le chargement des classes (classloader) différemment des autres serveurs d’application, à savoir les classes de WAS avant celles de l’application (PARENT FIRST). Résultat : des « ClassCastException », des « NoClassDefFoundError », des « NoSuchMethodException », …
Un très bon article, même s’il est un peu ancien, décrit bien ce problème. Plusieurs solutions existent pour pallier à ça et notamment celles qui m’avaient servit à l’époque sur WAS 5.1. Je vous laisse lire ce document IBM pour les détails.

Comme je le disais plus haut, la solution la plus simple est encore de ne pas l’utiliser quand on en n’a pas besoin. Dans le cas contraire, je vous conseille de regarder du côté de SLF4J.

SLF4J

Simple Logging Facade for Java (SL4J) est comme son nom l’indique une couche d’abstraction simple, pour faire comme ce bon vieux JCL… mais sans les problèmes de classloader. Comment ?
Tout simplement parce que contrairement à JCL qui charge dynamiquement à l’exécution l’implémentation (log4j, java.util), SLF4J le fait à la compilation et manuellement, en fonction de l’implémentation choisie (jar).

Exemple : Vous fournissez une api quelconque dans laquelle vous loggez des informations. Pour ce faire, vous avez besoin du jar de SLF4J slf4j-api-x.x.x.jar, et des différents adapteurs des frameworks (log4j : slf4j-log4j12-x.x.x.jar, java.util : slf4j-jdk14-x.x.x.jar) que les projets vous utilisant manipulent :

Simple d’utilisation :

(Vous aurez remarqué l’utilisation de {} pour jouer avec vos variables sans avoir à les concaténer à vos chaînes de caractères).

Plus de problème de classloading, vous fournissez tous les adapters disponibles (relativement légers : moins de 20 ko) et les projets utilisent leur framework de log préférés (log4j, java.util ou le plus récent logback qui apporte nativement l’adapteur SLF4J).

Conclusion

Pas sûr que les problèmes de classloading soient encore d’actualité sur les versions récentes de WAS, il n’empêche que JCL est vieillissant et quand on a degusté ces problèmes, on n’a plus envie de tenter le diable.
Au delà de sa simplicité et de la disparition du problème de classpath, SLF4J apporte un peu de fraîcheur (cf. exemple ci-dessus), alors n’hésitez plus, simplifiez vous la vie !