¿Vale la pena usar slf4j con log4j2?

114

No puedo decidir si usar slf4j o no con log4j2. Según las publicaciones en línea, no parece que tenga ningún impacto en el rendimiento, pero es realmente necesario.

Además, estos puntos gobiernan a favor de log4j2:

SLF4J obliga a su aplicación a registrar cadenas. La API de Log4j 2 admite el registro de cualquier CharSequence si desea registrar texto, pero también admite el registro de cualquier Objeto tal cual.
La API Log4j 2 ofrece soporte para el registro de objetos Message, expresiones lambda Java 8 y registro sin basura (evita la creación de matrices vararg y evita la creación de cadenas al registrar objetos CharSequence).

— Andy897
fuente

Tal vez. ¿Qué pasa si mi servidor de aplicaciones incluye un slf4jlogback (o log4jv1)? ¿Debería entonces verme obligado a instalar un tercer registrador para usar su aplicación? O tal vez la seguridad corporativa decide que solo puede usar java.util.loggingen producción, ¿entonces qué?

— Elliott Frisch

Gracias por escribir. Pero, si todos usan log4j org wide, el argumento anterior no será válido.

— Andy897

Usar SLF4J significa que reemplazar la implementación es muy fácil si la política de la empresa cambia, por ejemplo, cuando su empresa es adquirida y se le imponen nuevas políticas. Usar SLF4J ahora, cuando escriba el código, no tomará más tiempo que usar Log4j directamente. Reemplazar las llamadas directas de Log4j más tarde llevará mucho tiempo. SLF4J es una inversión / seguro gratuito para el futuro. ¿Es eso más importante que las características de la API de Log4j 2? Solo usted (o la política de la empresa) puede decidir eso.

— Andreas

¿Hay alguna forma de usar slf4j con log4j2 si quisiera? Esta página muestra el uso con log4j - versión 1.2 - que está al final de su vida útil), pero no hay opción para log4j2. Si hay una forma, ¿por qué slf4j no la menciona?

— J Woodchuck

162

Adelante: programe en la API log4j2 en lugar de slf4j

Es seguro: la API Log4j2 ofrece exactamente las mismas garantías que slf4j, y más.

Ahora que Log4j2 en sí está separado en una API y un módulo de implementación, ya no tiene ningún valor usar SLF4J.

Sí, es una buena práctica de ingeniería mantener abiertas sus opciones. Es posible que desee cambiar a otra implementación de registro más adelante.

Durante los últimos 10 años, construir tal flexibilidad en su aplicación significó usar una API contenedora como SLF4J. Sin embargo, esta flexibilidad no es gratuita: la desventaja de este enfoque es que su aplicación no puede usar el conjunto de características más completo de la biblioteca de registro subyacente.

Log4j2 ofrece una solución que no requiere que su aplicación esté restringida al mínimo común denominador.

La válvula de escape: log4j-to-slf4j

Log4j2 incluye un log4j-to-slf4jmódulo puente. Cualquier aplicación codificada con la API de Log4j2 puede optar por cambiar la implementación de respaldo a cualquier implementación compatible con slf4j en cualquier momento.

Como se menciona en la pregunta, el uso de la API Log4j2 ofrece directamente más funcionalidad y tiene algunas ventajas no funcionales en comparación con el uso de una API contenedora como slf4j:

API de mensajes
Lambdas para registro perezoso
Registra cualquier objeto en lugar de solo cadenas
Sin basura: evite crear varargs o crear cadenas cuando sea posible
CloseableThreadContext elimina automáticamente elementos del MDC cuando haya terminado con ellos

(Consulte 10 funciones de API de Log4j2 no disponibles en SLF4J para obtener más detalles).

Las aplicaciones pueden utilizar de forma segura estas características enriquecidas de la API de Log4j2 sin estar bloqueadas en la implementación central nativa de Log4j2.

SLF4J sigue siendo su válvula de seguridad, simplemente no significa que su aplicación deba codificarse más con la API SLF4J.

Divulgación: contribuyo a Log4j2.

Actualización: Parece haber cierta confusión en cuanto a que la programación de la API de Log4j2 de alguna manera introduce una "fachada por fachada". No hay diferencia a este respecto entre la API de Log4j2 y SLF4J.

Ambas API requieren 2 dependencias cuando se usa una implementación nativa y 4 dependencias para una implementación no nativa. SLF4J y la API Log4j2 son idénticas a este respecto. Por ejemplo:

Las dependencias requeridas son similares para SLF4J y la API Log4j 2

— Remko Popma
fuente

Entiendo. Permítame rehacer mi pregunta. ¿Existen implementaciones independientes de la API log4j2 además de log4j2?

— Ceki

La API Log4j2 y la impl no están "estrechamente acopladas". Todas estas implementaciones de SLF4J están disponibles: una aplicación codificada con la API de Log4j2 puede seleccionar la log4j-to-slf4jdependencia en lugar de log4j-corey elegir cualquiera de estas implementaciones de SLF4J que mencionaste. El número de implementaciones nativas de la API Log4j2 es irrelevante.

— Remko Popma

El problema es que a menudo tiene dependencias de bibliotecas que ellas mismas usan slf4j, por lo que es más fácil seguir con eso.

— Davio

Entonces, ¿debería usar una interfaz para una interfaz para una implementación? Sí, no, gracias ... Slf4j superó a log4j al proporcionar una buena interfaz de implementación para el registro ... log4j2 debería implementar slf4j api - si falta una característica, contribuya con ella, si slf4j no acepta la nueva característica, entonces TAL VEZ haya un caso para las interfaces api log4j2 ....

— RockMeetHardplace

@RemkoPopma: todavía está defendiendo el uso de la interfaz log4j. Sí, lo entiendo - puedo encadenar la interfaz de log4j2 -> interfaz de slf4j -> cualquier implementación, pero prefiero no abstraer la abstracción - gracias pero no gracias.

— RockMeetHardplace