¿Deberían los nuevos proyectos usar logback en lugar de log4j como un marco de registro?¿Los nuevos proyectos deberían usar logback en lugar de log4j?
O en otras palabras: '¿Logback es mejor que log4j (dejando el SLF4J-'feature' de logback al lado)? '
No estoy familiarizado con SLF4J, y solo he echado un vistazo breve al logback, pero me vienen a la mente dos cosas.
En primer lugar, ¿por qué se 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 herramienta. Hay, después de todo, sin bala de plata.
Para responder a su pregunta, sí y no. Depende del proyecto y de cuán familiarizado está el equipo con una herramienta. No diría "no use log4j" si todo el equipo está muy cómodo con él, cumple con todas las necesidades y logback no ofrece nada de lo que necesitamos para completar la tarea.
SLF4J es una fachada que usa logback. No dejo nada al lado. Es 'característica'. –
Ah. Gracias por aclarar, pero los puntos principales de mi respuesta todavía se aplican. –
¡Guau! Hable de ambigüedades ... reemplace 'log4j' y' logback' en esta respuesta para dos bibliotecas, idiomas, IDEs, etc. ¡y vea el resultado! ¡es asombroso! : D –
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. Así que a menos que tenga muchas extensiones para log4j en su base de código, continuaría con logback.
Creo que su decisión debería ser la misma que si decidiera usar log4j o Jakarta Commons Logging: ¿está desarrollando una biblioteca que se incluirá en otras aplicaciones? Si es así, no parece justo forzar a los usuarios de su biblioteca a usar también su biblioteca de registro preferida.
Si la respuesta es no, me gustaría ir con lo que es más fácil de agregar y con lo que se siente más cómodo. Parece que logback es tan extensible y confiable como log4j, así que si te sientes cómodo usándolo, adelante.
Si está desarrollando una biblioteca, use slf4j, ya que puede usar cualquier back-end sin las desventajas del registro de commons. Si está escribiendo una aplicación, use slf4j para poder usar logback. –
Usaría slf4j para iniciar sesión en todos los casos. Esto le permite elegir qué back-end de registro real desea usar, en tiempo de implementación en lugar de tiempo de código.
Esto ha demostrado ser muy valioso para mí. Me permite usar log4j en las antiguas JVM, y logback en más de 1.5 JVM, y también java.util.logging si es necesario.
Debe usar SLF4J + Logback para iniciar sesión.
Proporciona funciones claras como mensajes parametrizados y (a diferencia del registro de commons) un contexto de diagnóstico asignado (MDC, javadoc, documentation).
El uso de SLF4J hace que el backend de inicio de sesión se pueda intercambiar de una manera bastante elegante.
Además, SLF4J supports bridging de otros marcos de registro para la implementación SLF4J real que utilizará para que los eventos de registro de software de terceros aparezcan en sus registros unificados, con la excepción de java.util.logging que no puede estar puenteado de la misma manera que otros frameworks de registro.
El puente jul se explica en el javadocs de SLF4JBridgeHandler.
He tenido una muy buena experiencia usando la combinación de SLF4J + Logback en varios proyectos y el desarrollo de LOG4J se ha estancado.
SLF4J tiene las siguientes desventajas restantes:
¡LOL, acabo de recibir la insignia de Nigromante por esta respuesta! Gracias a todos los votantes;) Nunca esperé recibir ese ... – Huxi
El contexto de diagnóstico mapeado es una alternativa más poderosa al contexto de diagnóstico anidado –
Eso no es del todo cierto. En realidad, son conceptos ortogonales. El MDC es un Mapa mientras que el NDC es una Pila. Eche un vistazo a http://sourceforge.net/apps/trac/lilith/wiki/NestedDiagnosticContext para algunos ejemplos de uso. – Huxi
Logback más conscientes de Java EE:
en general (a partir del código de documentación) que es mantener en recipientes mente - cómo coexisten múltiples aplicaciones, cómo cargadores de clases implementadas etc. Contextos para los madereros, JNDI, configuración JMX incluyó etc.
del desarrollador prospectivo casi misma, Logback añade registro parametrizado (sin necesidad de utilizar si (logger.isDebugEnabled()) para evitar la sobrecarga de concatenación de cadenas)
Log4J - única ventaja gigante es el soporte JVM viejo, pequeño (IMO) NDC (Logba) ck solo MDC), algunas extensiones. Por ejemplo, escribí la extensión para configureAndWatch para Log4j, no existe tal Logback
El autor (de Logback y Log4j) tiene una lista de motivos para cambiar al http://logback.qos.ch/reasonsToSwitch.html.
Aquí hay algunos que sobresalieron en mí;
más rápida aplicación
Sobre la base de nuestro trabajo anterior sobre log4j, internos logback han sido re-escrito para llevar a cabo unas diez veces más rápido en ciertos crítica de ejecución caminos. Los componentes logback no solo son más rápidos, también tienen una huella de memoria más pequeña .
recarga automática de la configuración archivos
Logback-clásico puede recargar automáticamente su archivo de configuración en modificación. El proceso de escaneado es de forma rápida y segura, ya que no implica la creación de un hilo separado para escanear. Esta sutileza técnica de asegura que el logback juega dentro de los servidores de aplicaciones y en general dentro del entorno JEE .
trazas de la pila con los datos de embalaje
Cuando logback imprime una excepción, la traza pila se incluyen el embalaje datos.Aquí hay un seguimiento de la pila de muestra generado por la aplicación web logback-demo .
14: 28: 48,835 [btpool0-7] INFO cqldemo.prime.PrimeAction - 99 es un no válido valor java.lang.Exception: 99 es inválida
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:43 2) [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) [embarcadero-6.1.12.jar: 6.1.12] en ch.qos.logback.demo.UserServletFilter. doFilter (UserServletFilter.java:44) [classes /: na] en org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [embarcadero-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.je tty.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]
De lo anterior, se puede reconocer que la aplicación está utilizando Struts versión 1.2.9 y se desplegó bajo la versión 6.1.12 embarcadero. Por lo tanto, las trazas de pila informarán rápidamente al lector sobre las clases que entran en la excepción pero también el paquete y las versiones de paquete a las que pertenecen. Cuando sus clientes le envíen un seguimiento de la pila , como desarrollador no necesitará más tiempo para pedirle que le envíe información sobre las versiones de los paquetes que están utilizando. La información será parte de la pila trace. Consulte la conversión "% xThrowable" para obtener más información.
Esta característica puede ser bastante útil para el punto que algunos usuarios erróneamente consideran una característica de su IDE.
Eliminación automática de los viejos archivos de registro
Al establecer la propiedad de maxHistory TimeBasedRollingPolicy o SizeAndTimeBasedFNATP, puede controlar el número máximo de archivos archivados. Si su rodando política demanda vuelco mensual y desea mantener el valor de registros de un año, basta con establecer la propiedad maxHistory a 12. Los archivos de registro archivados mayores de 12 meses será eliminado automáticamente.
Puede haber un sesgo existe, pero el mismo tipo hizo escribir ambos marcos y si él está diciendo sobre el uso Logback Log4J él es probablemente vale la pena escuchar.
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ørnRavnAndersen ¿Qué motivos personales? Es un proyecto de código abierto. –
Es una larga historia. Te sugiero que abras una nueva pregunta si realmente quieres saber. –
¿Podría ampliar el motivo por el cual se cerró esta pregunta? –
Esta pregunta es útil para mí, votando para reabrir. –
¿Cómo diablos es esto "demasiado localizado"? Una gran cantidad de proyectos Java usan log4j. La cuestión de si se debe considerar "obsoleta" en favor del nuevo logback (cuyos autores parecen considerar que desaprueba log4j) es relevante para muchas personas y continuará siéndolo durante un tiempo. – EricS