Est-il utile d'utiliser slf4j avec log4j2 ?

Question

Je n'arrive pas à décider si je dois utiliser slf4j ou non avec log4j2. D'après les articles en ligne, il ne semble pas y avoir de perte de performance, mais est-ce vraiment nécessaire ?

Ces points jouent également en faveur de log4j2 :

• SLF4J oblige votre application à enregistrer des chaînes de caractères. L'API Log4j 2 prend en charge l'enregistrement de toute séquence de caractères si vous souhaitez enregistrer du texte, mais aussi l'enregistrement de tout objet tel quel.
• L'API Log4j 2 prend en charge l'enregistrement des objets Message, les expressions lambda Java 8 et l'enregistrement sans gaspillage (il évite de créer des tableaux de varargs et de créer des chaînes de caractères lors de l'enregistrement des objets CharSequence).

Answer 1

Allez-y : programmez avec l'API log4j2 au lieu de slf4j.

C'est sûr : l'API Log4j2 offre exactement les mêmes garanties que slf4j - et plus encore.

Maintenant que Log4j2 lui-même est séparé en une API et un module d'implémentation, il n'y a plus d'intérêt à utiliser SLF4J.

Oui, c'est une bonne pratique d'ingénierie de garder vos options ouvertes. Il se peut que vous souhaitiez passer à une autre implémentation de la journalisation plus tard.

Au cours des dix dernières années environ, l'intégration d'une telle flexibilité dans votre application nécessitait l'utilisation d'une API wrapper comme SLF4J. Cette flexibilité n'est cependant pas gratuite : l'inconvénient de cette approche est que votre application ne peut pas utiliser le jeu de fonctionnalités plus riche de la bibliothèque de journalisation sous-jacente.

Log4j2 offre une solution qui ne nécessite pas que votre application soit limitée au plus petit dénominateur commun.

La soupape d'échappement : log4j-to-slf4j

Log4j2 comprend un log4j-to-slf4j module de pont. Toute application codée avec l'API Log4j2 peut choisir de changer l'implémentation de sauvegarde pour une implémentation conforme à Slf4j à tout moment.

Comme mentionné dans la question, l'utilisation directe de l'API Log4j2 offre plus de fonctionnalités et présente certains avantages non fonctionnels par rapport à l'utilisation d'une API wrapper comme slf4j :

• Message API
• Lambdas pour la journalisation paresseuse
• Enregistrer tout objet au lieu de seulement des chaînes de caractères
• Sans déchets : éviter de créer des varargues ou des chaînes de caractères lorsque cela est possible.
• CloseableThreadContext supprime automatiquement les éléments du MDC lorsque vous n'en avez plus besoin.

(Voir 10 fonctionnalités de l'API Log4j2 non disponibles dans SLF4J pour plus de détails).

Les applications peuvent utiliser en toute sécurité ces riches fonctionnalités de l'API Log4j2 sans être enfermées dans l'implémentation native du noyau de Log4j2.

SLF4J est toujours votre soupape de sécurité, mais cela ne signifie plus que votre application doit coder contre l'API SLF4J.

---

Divulgation : Je contribue à Log4j2.

---

Mise à jour : il semble y avoir une certaine confusion sur le fait que la programmation de l'API Log4j2 introduit en quelque sorte une "façade pour une façade". Il n'y a aucune différence à cet égard entre l'API Log4j2 et SLF4J.

Les deux API nécessitent 2 dépendances lorsqu'on utilise une implémentation native, et 4 dépendances pour une implémentation non-native. SLF4J et l'API Log4j2 sont identiques à cet égard. Par exemple :