log4j vs logback

Question

Estamos usando log4j detrás de una envoltura autoadhesiva. Planeamos usar muchas más características ahora.

¿Deberíamos actualizar a logback?

(no me refiero el marco de una fachada como SLF4J)

Answer 1

No exactamente respondiendo a su pregunta, pero si pudiera alejarse de su envoltorio hecho a sí mismo, entonces hay Simple Logging Facade for Java (SLF4J) la que Hibernate ahora ha cambiado a (en lugar de registro de los comunes).

SLF4J no tiene ninguno de los problemas de cargador de clase o pérdidas de memoria observadas con Jakarta Commons Logging (JCL).

SLF4J admite el registro JDK, log4j y logback. Entonces, debería ser bastante fácil cambiar de log4j a logback cuando sea el momento adecuado.

Editar: Aplogies que no me había dejado claro. Estaba sugiriendo usar SLF4J para aislarse de tener que hacer una elección difícil entre log4j o logback.

Answer 2

Su decisión debe basarse en

• su necesidad real de estas características "más"; y
• su costo esperado de implementar el cambio.

Debe resistir el impulso de cambiar API solo porque es "más nuevo, más brillante, mejor". Sigo una política de "si no está roto, no lo patees".

Si su aplicación requiere un marco de registro muy sofisticado, es posible que desee considerar por qué.

Answer 3

Logback implementa de forma nativa la API SLF4J. Esto significa que si está utilizando logback, en realidad está usando la API SLF4J. Teóricamente, podría usar los aspectos internos de la API de inicio de sesión directamente para el registro, pero eso es muy desaconsejable. Toda la documentación de inicio de sesión y los ejemplos en los registradores están escritos en términos de la API SLF4J.

Por lo tanto, al usar logback, estarías usando SLF4J y si por algún motivo deseas volver a iniciar sesión en log4j, puedes hacerlo en unos minutos simplemente colocando slf4j-log4j12.jar en tu ruta de clase.

Al migrar de logback a Log4J, logback partes específicas, específicamente las contenidas en logback.xml archivo de configuración haría todavía necesitan ser migrado a su equivalente log4j, es decir log4j.properties. Al migrar en la otra dirección, la configuración de log4j, es decir, log4j.properties, debería convertirse a su equivalente de logback. Hay un on-line tool para eso. La cantidad de trabajo involucrada en la migración de archivos de configuración es mucho menor que el trabajo requerido para migrar llamadas de registrador diseminadas a través de todo el código fuente de su software y sus dependencias.

Answer 4

¿Lo debería usted? Sí.

¿Por qué? Log4J ha sido obsoleto por Logback.

¿Es urgente? Tal vez no.

¿Es indoloro? Probablemente, pero puede depender de sus declaraciones de registro.

Tenga en cuenta que si realmente desea aprovechar al máximo LogBack (o SLF4J), entonces realmente necesita escribir proper logging statements. Esto arrojará ventajas como un código más rápido debido a la evaluación perezosa y menos líneas de código porque puede evitar guardias.

Finalmente, recomiendo SLF4J. (¿Por qué recrear la rueda con su propia fachada?)

Answer 5

Proyecto maduro o incluso proyecto en las etapas de desarrollo probablemente pierda más que ganar de dicha actualización, en mi humilde opinión. El logback es ciertamente mucho más avanzado en una variedad de puntos, pero no hasta cierto punto para un reemplazo completo en un sistema en funcionamiento. Sin duda, consideraría el inicio de sesión para un nuevo desarrollo, pero el log4j existente es lo suficientemente bueno y maduro para todo lo que ya se haya lanzado y se haya encontrado con el usuario final. Esto es muy subjetivo, deberías ver que te cueste a ti mismo.

Answer 6

En el mundo de la tala, hay Fachadas (como Apache Commons Logging, slf4j o incluso Log4j 2.0 API) e implementaciones (Log4j 1 + 2, java.util.logging, TinyLog, Logback).

Básicamente debe reemplazar su envoltorio selfmade con slf4j IF y solo SI no está satisfecho con él por alguna razón. Si bien Apache Commons Logging en realidad no proporciona una API moderna, slf4j y la nueva fachada de Log4j 2 lo están proporcionando. Dado que un buen número de aplicaciones usan slf4j como un contenedor, podría tener sentido usar eso.

slf4j da un buen número de azúcar en la API, como en este ejemplo de documentos SLF4J:

logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

Es la sustitución de variables. Esto también es compatible con Log4j 2.

Sin embargo, debe tener en cuenta que slf4j está desarrollado por QOS que también mantienen logback. Log4j 2.0 se hornea en la Apache Software Foundation. En los últimos tres años, una comunidad vibrante y activa ha crecido allí nuevamente. Si aprecia Open Source como lo hace Apache Software Foundation con todas sus garantías, puede reconsiderar el uso de slf4j a favor para usar Log4j 2 directamente.

Tenga en cuenta:

En el pasado log4j 1 no se mantuvo activa, mientras que Logback era. Pero hoy las cosas son diferentes. Log4j 2 se mantiene activamente y se libera en un horario casi regular. También incluye muchas características modernas y -imho- hace un par de cosas mejor que Logback. Esto a veces es solo una cuestión de gusto y debe sacar sus propias conclusiones.

escribí una visión rápida de las nuevas características de Log4J 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html

Al leer verá que Log4J 2 se inspiró en Logback sino también por otros marcos de registro. Pero la base del código es diferente; no comparte casi nada con Log4j 1 y cero con Logback. Esto condujo a algunas mejoras como, por ejemplo, Log4j 2 opera con bytestreams en lugar de Strings under the hood. Además, no pierde eventos durante la reconfiguración.

Log4J 2 puede conectarse a una velocidad más alta que otros marcos sé: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html

Y siendo la comunidad de usuarios parece ser mucho más grande que Logbacks: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html

Dicho todo esto lo mejor es elegir el marcos de registro que se ajustan mejor a lo que desea lograr. No cambiaría un marco completo si deshabilitaba el inicio de sesión en el entorno de producción y simplemente realizaba el registro básico en mi aplicación. Sin embargo, si hace un poco más con el registro, simplemente mire las características proporcionadas por los frameworks y sus desarrolladores. Mientras recibes soporte comercial para Logback a través de QOS (escuché), actualmente no hay soporte comercial para Log4j 2. Por otro lado, si necesitas hacer un registro de auditoría y necesitas un alto rendimiento provisto por los appenders asincrónicos, tiene mucho sentido compruebe log4j 2.

Tenga en cuenta a pesar de toda la comodidad que proporcionan, las fachadas siempre comen un poco de rendimiento. Es posible que no lo afecte en absoluto, pero si tiene pocos recursos puede que necesite guardar todo lo que pueda tener.

Sin conocer mejor sus requisitos, es casi imposible dar una recomendación. Solo: no cambies solo porque mucha gente cambia. Cambia solo porque ves el valor de eso. Y la argumentación de que log4j está muerto ya no cuenta. Está vivo, y hace calor.

DESCARGO DE RESPONSABILIDAD: Actualmente soy VP, Apache Logging Services y también estoy involucrado en log4j.