Esta pregunta es útil para mí, votar para reabrir.
Eric Wilson
3
¿Cómo diablos es esto "demasiado localizado"? Una gran cantidad de proyectos Java utilizan log4j. La cuestión de si debería considerarse "desaprobado" a favor del logback más nuevo (cuyos autores parecen considerar que desaprueba log4j) es relevante para mucha gente y lo seguirá siendo durante algún tiempo.
EricS
Voté para reabrir, pero parece que solo hay mi voto presente.
skiphoppy
Votó para reabrir también; Supongo que está localizado en "java" y eso es lo suficientemente bueno: /
Paul Gregoire
Respuestas:
83
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.
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.
Tenga en cuenta que el autor tiene razones personales para querer que las personas cambien, por lo que la lista no es completamente imparcial.
Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen ¿Qué razones personales? Es un proyecto de código abierto.
Kshitiz Sharma
Es una larga historia. Le sugiero que abra una nueva pregunta si realmente quiere saberlo.
Thorbjørn Ravn Andersen
10
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.
Si está desarrollando una biblioteca, use slf4j, ya que puede usar cualquier backend sin las desventajas del registro común. Si está escribiendo una aplicación, use slf4j para poder usar logback.
David Roussel
-3
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.
SLF4J es una fachada que utiliza logback. No dejo nada al lado. Es una 'característica'.
¡Ah! Gracias por aclarar, pero los puntos principales de mi respuesta aún se aplican.
Thomas Owens
16
¡Guauu! Hable de ambiguo ... reemplace log4jy logbacken esta respuesta para dos bibliotecas, idiomas, IDE, etc., ¡y vea el resultado! ¡es asombroso! : D
Respuestas:
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:
fuente
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.
fuente
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.
fuente
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
fuente
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.
fuente
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.
fuente
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.
fuente
log4jylogbacken esta respuesta para dos bibliotecas, idiomas, IDE, etc., ¡y vea el resultado! ¡es asombroso! : D