Est-il utile d'utiliser slf4j avec log4j2
Je ne suis pas en mesure de décider d'utiliser slf4j ou non avec log4j2. Basé sur des publications en ligne, il ne semble pas que cela aura un impact sur les performances, mais est-il vraiment requis.
De plus, ces points sont favorables à log4j2:
- SLF4J oblige votre application à journaliser les chaînes. L'API Log4j 2 prend en charge la consignation de CharSequence si vous souhaitez consigner du texte, mais prend également en charge la consignation de tout objet tel quel.
- L'API Log4j 2 prend en charge la journalisation des objets Message, Java 8 expressions lambda et de la journalisation sans ordures (elle évite la création de tableaux de type vararg et la création de chaînes de caractères lors de la journalisation d'objets CharSequence).
Allez-y: programmez l'API log4j2 au lieu de slf4j
C'est sûr: l'API Log4j2 offre exactement les mêmes garanties que slf4j - et plus.
Maintenant que Log4j2 est séparé en une API et un module d'implémentation, l'utilisation de SLF4J n'a plus aucune valeur.
Oui, il est judicieux de garder vos options ouvertes. Vous voudrez peut-être passer ultérieurement à une autre implémentation de journalisation.
Au cours des 10 dernières années environ, pour créer une telle flexibilité dans votre application, vous avez utilisé une API wrapper telle que SLF4J. Cette flexibilité n’est cependant pas gratuite: son inconvénient est que votre application ne peut pas utiliser le jeu de fonctionnalités plus riche de la bibliothèque de consignation sous-jacente.
Log4j2 offre une solution qui n'exige pas que votre application soit limitée au plus petit dénominateur commun.
La soupape d'échappement: log4j-to-slf4j
Log4j2 comprend un module de pont log4j-to-slf4j. Toute application codée par rapport à l'API Log4j2 peut choisir de passer à tout moment de l'implémentation de sauvegarde à toute implémentation compatible slf4j.
Comme indiqué dans la question, l'utilisation de l'API Log4j2 offre directement davantage de fonctionnalités et présente certains avantages non fonctionnels par rapport à l'utilisation d'une API wrapper telle que slf4j:
- API de message
- Lambdas pour la journalisation paresseuse
- Journalise n'importe quel objet plutôt que juste des chaînes
- Sans déchets: évitez de créer des varargs ou de créer des chaînes si possible
- CloseableThreadContext supprime automatiquement les éléments du MDC lorsque vous avez terminé.
(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 fonctionnalités riches de l'API Log4j2 sans être verrouillées dans l'implémentation logique native de Log4j2.
SLF4J est toujours votre soupape de sécurité, cela ne signifie simplement pas que votre application doit désormais coder contre l'API SLF4J.
Divulgation: Je contribue à Log4j2.
Mise à jour: Il semble y avoir une certaine confusion quant à la programmation de l’API Log4j2 qui introduit en quelque sorte une "façade pour une façade". Il n'y a pas de différence à cet égard entre l'API Log4j2 et SLF4J.
Les deux API nécessitent 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:
