Bonsoir, J'ai écrit l'implémentation initiale de LogTools#getLog(), qui a apparemment évoluée depuis. L'unique avantage est de pouvoir copier-coller cette ligne d'une classe à l'autre sans risque d'erreur. C'est moins performant que la méthode classique — LoggerFactory.getLogger(HelloWorld.class) — puisqu'il s'agit de générer une exception, d'analyser la stacktrace pour récupérer la classe appelante et enfin de générer le logger adéquate. Générer une exception est coûteux et généralement déconseillé, mais j'avais jugé ce surcoût négligeable dans une telle application. Revenir à la méthode plus conventionnelle est une bonne idée, car plus compréhensible pour les autres développeurs. Concernant le nom de la variable, j'ai une préférence pour le nom concis (LOG), mais il s'agit seulement là d'une habitude ou d'une question de goût. Cordialement, Mickaël On 01/02/2013 18:13, Eric Chatellier wrote:
Actuellement nous avons: private static final Log LOG = LogTools.getLog();
La convention slf4j est plutôt:
private static final Logger logger = LoggerFactory.getLogger(HelloWorld.class); Ce qui implique de renommer aussi la variable "LOG" en LOGGER dans toute la classe également.
La modification est plus importante que modifier une seule ligne dans chaque classe.
Une autre question. C'est la première fois que je vois la déclaration des logs de façon générique: private static final Log LOG = LogTools.getLog(); qui récupère un Log sur la classe en haut de la stack actuelle.
Je suis curieux de savoir si c'est performant et s'il y a une source qui explique les avantages (voire pourquoi ce n'est pas plus répandu).
Ce mécanisme utilise, de plus, un import "sun.reflect.Reflection" (dans nc.ird.module.utils.GenericsTools) qui est déconseillé.