Les nouveaux projets doivent-ils utiliser logback au lieu de log4j ?

Question

Les nouveaux projets devraient-ils utiliser logback au lieu de log4j comme cadre de journalisation ?

Ou avec d'autres mots : 'Est-ce que logback est meilleur que log4j (en laissant de côté la 'caractéristique' SLF4J de logback) ?

Answer 1

Je pense que votre décision devrait être la même que si vous décidiez d'utiliser log4j ou Jakarta Commons Logging : développez-vous une bibliothèque qui sera incluse dans d'autres applications ? Si c'est le cas, il ne semble pas juste de forcer les utilisateurs de votre bibliothèque à utiliser également la bibliothèque de journalisation de votre choix.

Si la réponse est non, je choisirais ce qui est le plus simple à ajouter et ce avec quoi vous êtes le plus à l'aise. Il semble que logback soit tout aussi extensible et fiable que log4j, donc si vous êtes à l'aise pour l'utiliser, allez-y.

Answer 2

Je ne suis pas familier avec SLF4J, et je n'ai jeté qu'un bref coup d'œil à logback, mais deux choses me viennent à l'esprit.

Premièrement, pourquoi exclure un outil de l'examen ? Je pense qu'il est important de garder l'esprit ouvert et d'examiner toutes les possibilités pour choisir la meilleure.

Deuxièmement, je pense que dans certains projets, un outil est meilleur qu'un autre, et que le contraire peut être vrai dans un autre projet. Je ne pense pas qu'un outil soit toujours meilleur qu'un autre. Il y en a, après tout, pas de solution miracle .

Pour répondre à votre question - Oui et non. Cela dépend du projet et du degré de familiarité de l'équipe avec un outil. Je ne dirais pas "n'utilisez pas log4j" si toute l'équipe est très à l'aise avec cet outil, s'il répond à tous les besoins et si logback n'offre rien de ce dont nous avons besoin pour accomplir la tâche.