Bonjour, Je suis le développeur initial du projet et je lis cette mailing-liste avec curiosité (nostalgie ?). Il me semble avoir fait l'erreur au départ du projet de baser les logs de l'application sur commons-logging, alors que slf4j est bien plus puissant et moins poussiéreux. Aujourd'hui, je partirais sur une solution slf4j <http://www.slf4j.org/> en façade + logback <http://logback.qos.ch/> en implémentation native (ces librairies ayant été développées par le créateur de log4j). Le projet log4j a été repris assez récemment et semble prometteur, néanmoins log4j2 <http://logging.apache.org/log4j/2.x/> n'est encore disponible qu'en beta. Dans tous les cas il faut rediriger les logs provenant d'API tierces vers la solution choisie (voir : bridging legacy APIs <http://www.slf4j.org/legacy.html>) Je serais pour ma part tenté de procéder comme ceci : * déclarer slf4j comme (seule) dépendance "compile" * déclarer logback, commons-logging, log4j-over-slf4j, jcl-over-slf4j (et peut-être jul-to-slf4j) comme dépendances "runtime" * corriger les problèmes de compilation dans le code Java * remplacer les fichiers de configuration log4j par des fichiers de configuration logback Cordialement, Mickaël