Utilisation de sjf4j ou de commons-logging
Bonjour, Dans l'application, les dependances de logging n'ont pas été configurée (ou elles ont changés lors du changement de forge). L'application à l'air d'être basée sur commons-logging, mais hibernate utilisant slf4j, on doit quand même le prendre en compte. La modification des fichiers log4j.xml n'est pas prise en compte actuellement (log verbeux de hibernate en debug). Actuellement la dépendance "jcl-over-slf4j" est présente dans le projet (c'est à dire redirection de commons-logging vers slf4j). Je serais plutôt tenté de faire l'inverse: * baser l'application sur commons-logging * utiliser l'impl slf4j qui redirige sur commons-logging (slf4j-jcl) * et utiliser l'implémentation log4j Êtes vous d'accord avec l'utilisation principale de commons-logging à la place de slf4j ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
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
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
participants (2)
-
Eric Chatellier -
Mickaël Tricot