Bonjour, Je reviens de congés et me permet d'apporter mon grain de sable à cette discussion. Comme le rappelle Mickaël, l'application repose depuis ses débuts sur common-logging. Cependant puisque Hibernate utilise slf4j, le choix a été fait (par Mickaël notamment) d'utiliser la "bridging legacy API" jcl-over-slf4j. Ainsi, tous les logs peuvent être redirigés sur SLF4j et ce dernier est configuré avec l'implémentation log4j (slf4j-log4j12). Cette configuration fonctionnait correctement jusqu'à récemment. En effet Éric, il y a certainement un conflit de version dans les dépendances depuis que Cantharella est passé sur la forge de Code Lutin et qu'il a bénéficié par la même occasion de mises à jour sur un bon nombre de ses librairies. J'ai regardé un peu pour résoudre le problème mais j'arrive qu'à obtenir soit les logs qui proviennent du code source (commons-loggin), soit ceux qui proviennent d'hibernate (slf4j). Sinon, il est certain qu'on peut améliorer l'architecture, cela sera certainement plus rapide que de corriger le problème actuel. Bien que vos propositions me semblent toutes deux aller dans le bon sens, je serais plus d'avis à utiliser directement slf4j car elle a davantage de fonctionnalités, qu'elle me semble actuellement plus reconnue dans la communauté Java, et que cela permet de s'affranchir de common-logging (contrairement à l'autre cas, où l'on doit garder slf4j pour hibernate). Si cette solution est retenue, on peut alors soit continuer de garder log4j ou bien comme le suggère Mickaël migrer vers son "successeur" logback. Là, mon avis est plus mitigé, tout dépend du temps qu'on veut y passer. Log4j marche déjà bien mais logback peut avoir ses avantages... Et bienvenue à Mickaël dans la mailing-list ! N'hésite pas à participer de nouveau, on a toujours besoin l'avis d'un architecte Octo ;) Bonne journée, Adrien Le 22/01/2013 04:31, Eric Chatellier a écrit :

...

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 suis d'accord avec vous, je suis plus fan de slf4j que commons-logging également.

Mais, les avis divergent (même au sein de codelutin) quant à l'utiliser à la place de commons-logging pour diverses raisons, la principale étant que fondamentalement, slf4j et commons-logging font la même chose (une interface sur une implémentation qui peut changer) et que le remplacement n'est pas forcement justifié.

Je serais tenté d'attendre au moins un avis de plus avant toute action :-)

-- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789