Est-il utile d’utiliser slf4j avec log4j2

Je ne peux pas décider d’utiliser slf4j ou non avec log4j2. Basé sur des publications en ligne, ne semble pas avoir un impact sur la performance, mais est-ce vraiment nécessaire.

De plus, ces points sont en faveur de log4j2:

  • SLF4J force votre application à enregistrer des chaînes. L’API Log4j 2 prend en charge la consignation de toute CharSequence si vous souhaitez consigner du texte, mais prend également en charge la consignation de tout object tel quel.
  • L’API Log4j 2 prend en charge la journalisation des objects Message, des expressions lambda Java 8 et la journalisation sans déchets (cela évite de créer des tableaux vararg et évite de créer des chaînes lors de la journalisation des objects CharSequence).

Allez-y: programmez sur 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, l’utilisation de SLF4J n’a plus aucune valeur.

Oui, garder vos options ouvertes est une bonne pratique technique. Vous souhaiterez peut-être modifier ultérieurement une autre implémentation de journalisation.

Au cours des 10 dernières années, la création d’une telle flexibilité dans votre application a nécessité 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 valve d’échappement: log4j-to-slf4j

Log4j2 inclut un module de pont log4j-to-slf4j . Toute application codée sur l’API Log4j2 peut choisir de basculer l’implémentation de backing vers n’importe quelle implémentation compatible slf4j à tout moment.

log4j-à-slf4j

Comme mentionné dans la question, l’utilisation de l’API Log4j2 offre plus de fonctionnalités et présente des avantages non fonctionnels par rapport à l’utilisation d’une API wrapper telle que slf4j:

  • API de message
  • Lambdas pour la journalisation paresseuse
  • Connectez un object au lieu de simplement des chaînes
  • Sans déchets: évitez de créer des varargs ou de créer des chaînes dans la mesure du possible
  • CloseableThreadContext supprime automatiquement les éléments du MDC lorsque vous en avez fini avec eux

(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 bloquées dans l’implémentation principale native de Log4j2.

SLF4J est toujours votre soupape de sécurité, cela ne signifie tout simplement pas que votre application devrait coder contre l’API SLF4J.


Disclaimer: Je consortingbue à Log4j2.


Mise à jour: Il semble y avoir une certaine confusion que la programmation de l’API Log4j2 introduit d’une manière ou d’une autre une “façade pour une façade”. Il n’y a pas de différence à cet égard entre les API Log4j2 et SLF4J.

Les deux API requièrent 2 dépendances lors de l’utilisation d’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:

Les dépendances requises sont similaires pour SLF4J et l'API Log4j 2