Dans le monde de la journalisation, il existe des façades (comme Apache Commons Logging, slf4j ou même l'API Log4j 2.0) et des implémentations (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
En gros, vous devriez remplacer votre propre wrapper par slf4j IF et seulement SI vous n'en êtes pas satisfait pour une raison quelconque. Alors qu'Apache Commons Logging ne fournit pas vraiment une API moderne, slf4j et la nouvelle façade Log4j 2 le fournissent. Étant donné que de nombreuses applications utilisent slf4j comme wrapper, il peut être judicieux de l'utiliser.
slf4j donne un certain nombre de sucre API sympa, comme cet exemple de la documentation slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
C'est une substitution variable. Ceci est également pris en charge par Log4j 2.
Cependant, vous devez être conscient que slf4j est développé par QOS qui gère également le retour de connexion. Log4j 2.0 est intégré à Apache Software Foundation. Au cours des trois dernières années, une communauté dynamique et active s'est de nouveau développée. Si vous appréciez l'Open Source comme cela est fait par l'Apache Software Foundation avec toutes ses garanties, vous pouvez reconsidérer l'utilisation de slf4j en faveur d'utiliser Log4j 2 directement.
Notez s'il vous plaît:
Dans le passé, log4j 1 n'était pas activement maintenu alors que Logback l'était. Mais aujourd'hui, les choses sont différentes. Log4j 2 est activement maintenu et sort sur un calendrier presque régulier. Il comprend également de nombreuses fonctionnalités modernes et -imho- rend deux choses meilleures que Logback. C'est parfois juste une question de goût et vous devriez tirer vos propres conclusions.
J'ai rédigé un bref aperçu des nouvelles fonctionnalités de Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
A la lecture, vous verrez que Log4j 2 a été inspiré par Logback mais aussi par d'autres frameworks de journalisation. Mais la base de code est différente; il ne partage presque rien avec Log4j 1 et zéro avec Logback. Cela a conduit à quelques améliorations comme dans l'exemple Log4j 2 fonctionne avec bytestreams au lieu de Strings sous le capot. De plus, il ne perd pas d'événements lors de la reconfiguration.
Log4j 2 peut se connecter à une vitesse plus élevée que les autres frameworks que je connais: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
Et toujours la communauté des utilisateurs semble être beaucoup plus grande que Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
Cela dit, la meilleure idée est de choisir les cadres de journalisation qui correspondent le mieux à ce que vous souhaitez réaliser. Je ne changerais pas de cadre complet si je désactivais la journalisation dans l'environnement de production et effectuais simplement une journalisation de base dans mon application. Cependant, si vous faites un peu plus avec la journalisation, regardez simplement les fonctionnalités fournies par les frameworks et leurs développeurs. Bien que vous bénéficiez d'un support commercial pour Logback via QOS (j'ai entendu dire), il n'y a actuellement aucun support commercial pour Log4j 2. D'un autre côté, si vous avez besoin de faire une journalisation d'audit et que vous avez besoin de hautes performances fournies par les appenders asynchrones, il est très logique de vérifier log4j 2.
Attention malgré tout le confort qu'elles procurent, les façades mangent toujours un peu de performance. Cela ne vous affecte peut-être pas du tout, mais si vous manquez de ressources, vous devrez peut-être sauvegarder tout ce que vous pouvez avoir.
Sans mieux connaître vos besoins, il est presque impossible de donner une recommandation. Juste: ne changez pas simplement parce que beaucoup de gens changent. Ne changez que parce que vous en voyez la valeur. Et l'argumentation selon laquelle log4j est mort ne compte plus. Il est vivant et il fait chaud.
AVIS DE NON-RESPONSABILITÉ: Je suis actuellement vice-président des services de journalisation Apache et je suis également impliqué dans log4j.