migrando un proyecto de log4j a slf4j + log4j

Question

Tengo un gran proyecto web que usa log4j directamente, junto con muchas bibliotecas de terceros y una combinación de bibliotecas de registro.

• nuestro código base - usa log4j directamente.
• Hibernate: utiliza slf4j y el enlace slf4j-log4j.
• Primavera: utiliza registros comunes. Por lo tanto, utiliza el jcl-over-slf4j bridge api, slf4j itself y slf4j-log4j binding.
• Otras bibliotecas numerosas, que utilizan registros comunes o log4j.

Estoy considerando migrar nuestro propio código base a slf4j api, pero no estoy seguro si los beneficios son lo suficientemente fuertes y vale la pena el esfuerzo. Actualmente estoy al tanto de los siguientes beneficios:

• Cleaner api.
• Mejoras de rendimiento: la capacidad de utilizar métodos de registro parametrizados.
• Posibilidad de cambiar fácilmente a logback en el futuro (actualmente el logback está descartado).
• No hay necesidad de frascos adicionales, ya que los tengo.

¿Hay algún otro beneficio? ¿Hay algún inconveniente del que no tengo conocimiento todavía?

Answer 1

El único beneficio que veo para cambiar es que puede canalizar todos los marcos de registro a través de un solo marco, lo que puede simplificar su configuración.

Probablemente las razones principales por las que me mudé a slf4j (esto solo se aplica a slf4j + logback) es que puede reload the configuration via JMX, lo cual es EXCELENTE cuando tiene un problema que desaparece con el reinicio de un servidor.

Answer 2

Para mí, hay cuatro características "asesinas", que eran vale la pena el dolor en el movimiento hacia Logback, en la parte superior de los que ya se ha mencionado (personalmente me cambió mi gran proyecto actual, que trabajan sin problemas):

• Recarga automática de archivos de configuración. Esto es asombroso para los sistemas de producción. Si solo quiere establecer "depuración" en una clase, pero no derribar todo el sistema, este no tiene precio.
• La capacidad de usar incluye archivos en la configuración. Esto le permite tener un conjunto "maestro" de configuraciones de registro para todos sus servicios/JVM, y luego puede especificar cualquier paquete que pueda requerir un procesamiento especial. Tenemos aproximadamente ~ 10 servicios actualmente, y tienen todos una copia grande, pero principalmente similar, de log4j.xml. Ahora lo estamos cambiando a un archivo de configuración de inicio de sesión principal, y tenemos ese archivo incluido en el archivo de configuración de inicio de sesión de cada servicio. El archivo maestro seguirá siendo grande, pero los específicos del servicio deberían ser muy pequeños. Mucho más mantenible.
• Procesamiento condicional. De esta forma puede especificar cosas como "si QAServer => luego configure los niveles de registro en" DEBUG ", sino" INFO ". De nuevo, ideal para tener una única configuración que no tenga que cambiar entre los servidores de producción y dev/QA.
• Compresión automática y eliminación de archivos de registro antiguos Puede especificar cuántos archivos archivados desea conservar y, opcionalmente, comprimirlos.Después de crear el archivo n + 1, detectará que hay uno demasiado y borrará el más antiguo. Nuevamente, configurable por archivo/servicio, sin necesidad de hacer nada específico del sistema (archivos por lotes y/o scripts).

Por cierto, después de hacer este cambio, es trivialmente fácil volver a iniciar sesión en log4j. Debido a que la migración a Logback requiere el uso de SLF4J, que Log4j también admite, el cambio de ida y vuelta solo requiere que elija qué archivo jar para descartar (Log4j o Logback). Siempre que los archivos de configuración log4j.xml o logback correspondientes estén en la ruta de clases, el registro funcionará correctamente.