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 en façade + logback 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 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)

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