¿Deberían los nuevos proyectos utilizar logback en lugar de log4j? [cerrado]

¿Deberían los nuevos proyectos utilizar logback en lugar de log4j como marco de registro?

O con otras palabras: '¿Logback es mejor que log4j (dejando la' característica 'SLF4J de logback al lado)?'

Debe utilizar SLF4J + Logback para el registro.

Proporciona características interesantes como mensajes parametrizados y (en contraste con el registro común) un contexto de diagnóstico mapeado (MDC, javadoc , documentación ).

El uso de SLF4J hace que el backend de registro sea intercambiable de una manera bastante elegante.

Además, SLF4J admite el enlace de otros marcos de registro con la implementación real de SLF4J que utilizará, por lo que los eventos de registro de software de terceros se mostrarán en sus registros unificados, con la excepción de java.util.logging que no se puede puentear el de la misma forma que otros marcos de registro.

Bridging jul se explica en los javadocs de SLF4JBridgeHandler.

He tenido una muy buena experiencia usando la combinación SLF4J + Logback en varios proyectos y el desarrollo de LOG4J se ha estancado bastante.

SLF4J tiene las siguientes desventajas restantes:

• No admite varargs para seguir siendo compatible con Java <1.5
• No admite el uso de mensajes parametrizados y una excepción al mismo tiempo.
• No contiene soporte para un contexto de diagnóstico anidado (NDC, javadoc ) que tiene LOG4J.

El autor (tanto de Logback como de Log4j) tiene una lista de razones para cambiar en http://logback.qos.ch/reasonsToSwitch.html .

Aquí hay algunos que me llamaron la atención;

• Implementación más rápida

  Basado en nuestro trabajo anterior en log4j, los componentes internos de logback se han reescrito para funcionar unas diez veces más rápido en ciertas rutas de ejecución críticas. Los componentes de logback no solo son más rápidos, sino que también tienen una menor huella de memoria.

• Recarga automática de archivos de configuración

  Logback-classic puede volver a cargar automáticamente su archivo de configuración tras la modificación. El proceso de escaneo es rápido y seguro, ya que no implica la creación de un hilo separado para escanear. Esta sutileza técnica asegura que el logback funcione bien dentro de los servidores de aplicaciones y, de manera más general, dentro del entorno JEE.

• Apilar seguimientos con datos de empaquetado

  Cuando el logback imprime una excepción, el seguimiento de la pila incluirá datos de empaque. Aquí hay un ejemplo de seguimiento de pila generado por la aplicación web logback-demo.

  14: 28: 48.835 [btpool0-7] INFO cqldemo.prime.PrimeAction - 99 no es un valor válido java.lang.Exception: 99 no es válido
  en ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java : 28) [classes /: na] en org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] en org.apache.struts.action. RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] en org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar : 1.2.9] en javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar: 6.1.12]
  en org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:502) [jetty-6.1.12.jar: 6.1.12] en ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44 ) [clases /: na] en org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [jetty-6.1.12.jar: 6.1.12] en org.mortbay.jetty.servlet. ServletHandler.handle (ServletHandler.java:361) [embarcadero-6.1.12.jar: 6.1.12] en org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [embarcadero-6.1.12.jar : 6.1.12] en org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [embarcadero-6.1.12.jar: 6.1.12]

  Por lo anterior, puede reconocer que la aplicación está usando Struts versión 1.2.9 y se implementó bajo la versión de embarcadero 6.1.12. Por lo tanto, los seguimientos de pila informarán rápidamente al lector sobre las clases que invierten en la excepción, pero también sobre el paquete y las versiones de paquete a las que pertenecen. Cuando sus clientes le envíen un seguimiento de pila, como desarrollador, ya no necesitará pedirles que le envíen información sobre las versiones de los paquetes que están usando. La información será parte del seguimiento de la pila. Consulte la palabra de conversión "% xThrowable" para obtener más detalles.

  Esta característica puede ser bastante útil hasta el punto de que algunos usuarios la consideran erróneamente una característica de su IDE.

• Eliminación automática de archivos de registro antiguos

  Al establecer la propiedad maxHistory de TimeBasedRollingPolicy o SizeAndTimeBasedFNATP, puede controlar el número máximo de archivos archivados. Si su política de renovación requiere una renovación mensual y desea conservar los registros de un año, simplemente establezca la propiedad maxHistory en 12. Los archivos de registro archivados con más de 12 meses de antigüedad se eliminarán automáticamente.

Puede haber un sesgo allí, pero el mismo tipo escribió ambos marcos y si está diciendo que use Logback sobre Log4j, probablemente valga la pena escucharlo.

Usaría slf4j para iniciar sesión en todos los casos. Esto le permite elegir qué backend de registro real desea usar, en el momento de la implementación en lugar del tiempo del código.

Esto ha demostrado ser muy valioso para mí. Me permite usar log4j en JVM antiguas y logback en 1.5+ JVM, y también java.util.logging si es necesario.

Logback más consciente de Java EE:
en general (desde el código hasta la documentación) se tiene en cuenta los contenedores: cómo coexisten múltiples aplicaciones, cómo se implementan los cargadores de clases, etc. Contextos para registradores, configuración JNDI, JMX incluida, etc.

desde el desarrollador prospectivo casi lo mismo, Logback agrega registro parametrizado (no es necesario usar if (logger.isDebugEnabled ()) para evitar la sobrecarga de concatenación de cadenas)

Log4j: el único plus gigante es el antiguo soporte JVM, pequeño (IMO) NDC (Logback solo MDC), algunas extensiones. Por ejemplo, escribí la extensión para configureAndWatch para Log4j, no hay tal cosa para Logback

el log4j y el logback originales fueron diseñados e implementados por el mismo tipo.

Varias herramientas de código abierto han utilizado SLF4J. No veo ninguna deficiencia significativa en esta herramienta. Entonces, a menos que tenga muchas extensiones para log4j en su código base, seguiría adelante con logback.

Creo que su decisión debería ser la misma que tomaría si estuviera decidiendo entre usar log4j o Jakarta Commons Logging: ¿está desarrollando una biblioteca que se incluirá en otras aplicaciones? Si es así, no parece justo obligar a los usuarios de su biblioteca a usar también la biblioteca de registro de su elección.

Si la respuesta es no, simplemente elegiría lo que sea más simple de agregar y con lo que se sienta más cómodo. Parece que el logback es tan extensible y confiable como log4j, así que si se siente cómodo usándolo, adelante.

No estoy familiarizado con SLF4J, y solo he echado un vistazo breve al logback, pero me vienen a la mente dos cosas.

Primero, ¿por qué excluye una herramienta del examen? Creo que es importante mantener la mente abierta y examinar todas las posibilidades para elegir la mejor.

En segundo lugar, creo que en algunos proyectos una herramienta es mejor que otra, y lo contrario podría ser cierto en un proyecto diferente. No creo que una herramienta sea siempre mejor que otra. Después de todo, no existe una fórmula mágica .

Para responder a su pregunta, sí y no. Depende del proyecto y de lo familiarizado que esté el equipo con una herramienta. No diría "no use log4j" si todo el equipo está muy cómodo con él, satisface todas las necesidades y el logback no ofrece nada que necesitemos para completar la tarea.