Le 18/01/2013 20:47, Mickaël Tricot a écrit :
Bonjour, Bonjour,
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 :-) -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com