¿Se está abandonando Log4j a favor de Slf4j?

Question

Parece que log4j tiene algunos class loading issues (entre otros) y me parece que la tendencia es salir de log4j hacia slf4j. (Hibernate dejó de usar el primero a favor de este último)

1. ¿Es cierto?
2. ¿Cuáles son los principales problemas en log4j que resuelve slf4j?
3. ¿Es slf4j la última palabra o existe incluso un mejor estándar de la industria "el siguiente próximo log4j"?

Actualización:

• Así que este answer por delfuego me confunde, se puede aceptar/objetar que ?:

Usted parece haber tropezado con el problema principal con log4j (y la biblioteca de registro de Apache Commons ), es decir que tienen un ridículamente tiempo difícil para descubrir e interactuar con los cargadores de clases correctos, ya que están usando . Hay una explicación muy densa de , completa con ejemplos, aquí; el mensaje para llevar a casa es que una de las principales fuerzas motrices para el nuevo marco de trabajo de registro SLF4J era eliminar estos problemas por completo. Usted podría querer cambiarlo y ver si su vida se hace más fácil.

• Más problemas de carga de clase por log4j: http://articles.qos.ch/classloader.html

Answer 1

Slf4j es de hecho solo una fachada de explotación maderera. Sin embargo, Log4j está destinado a ser sucedido por Logback, de los mismos autores.

actualización: si desea saber sobre otro beneficio de SLF4J, es el hecho de que después (feo) construcciones ya no son necesarios para evitar la toString() innecesariamente sido llamado:

if (logger.isDebugEnabled()) { 
    logger.debug("Message: " + bigObject + ", " + anotherBigObject); 
} 

en su lugar puede hacer uso de mensajes con parámetros:

logger.debug("Message: {}, {}", bigObject, anotherBigObject); 

también ver What is the fastest way of (not) logging?

Answer 2

Mirando el slf4j page no se ve como que sería reemplazar log4j - sólo se le permitirá utilizar el mismo marco de registro subyacente (por ejemplo, log4j) para toda su aplicación, lo que permite que las bibliotecas se conecten automáticamente.

Parece más un reemplazo para Apache Commons Logging que log4j.

Answer 3

SLF4J tiene, en mi opinión, la gran ventaja de que puede unificar el registro de todas las bibliotecas que utiliza a través de los puentes que proporciona. Ninguno de los otros marcos de registro lo permite. Esto permite que los proyectos se muevan sin problemas a SLF4J e ignoren las opciones de marco de registro que las dependencias han creado.

Answer 4

Slf4J no es una alternativa para Log4j, sino que proporciona una fachada para el registro, por lo que uno puede conectar su propio marco de registro. Es principalmente útil para las bibliotecas. de slf4j.org:

el registro de la fachada simple para Java o (SLF4J) sirve como una fachada simple o abstracción para diversos marcos de registro , por ejemplo java.util.logging, log4j y logback, permitiendo que el usuario final conecte el marco de registro deseado en el momento del despliegue.

Para responder a su pregunta: SLF4J está siendo adoptado por los marcos ahora, pero en sus proyectos, se puede seguir utilizando Log4J (o cualquier otra)

Answer 5

Primera: un punto importante: SLF4J es la tala frontend (la API), que puede usarse debajo de la mayoría de los principales sistemas de inicio de sesión: log4j o java.util.logging, por ejemplo. Por lo tanto, es mejor comparar sfl4j a commons-logging.

Sobre el estado de Log4j, citas de The state of java logging (hace un año)

Una cosa que no me había dado cuenta es que el desarrollo de log4j es esencialmente muerto. Actualmente se encuentra en la versión 1.2, y los planes para la versión 1.3 fueron abandonados a favor del desarrollo de log4j 2.0. Sin embargo, no parece que 2.0 esté en desarrollo activo. Vale la pena señalar que Ceki Gülcü, el fundador original del proyecto log4j, ha pasado a slf4j (ver a continuación).

Answer 6

Slf4j no es una fachada de registro real. Slf4j no admite muchas características de sus implementadores. Para abreviar, menciono los ejemplos de log4j a continuación.

• SLF4J no puede especificar un archivo de configuración seleccionada por el usuario, pero las fuerzas de usuario utilizar por defecto (o log4j.properties log4j.xml) en una de tantas raíces Java (cada frasco tiene una raíz más JVM raíz y clases o bin) Si dos archivos JAR lo tienen, es difícil controlar cuál usar de forma segura.
• Slf4j no puede admitir todos los niveles de Log4j, como 'fatal'. Cuando se cambia el código grande de Log4j a Slf4j, se necesita un gran esfuerzo de cambio de código (por ejemplo, decidir cómo reorganizar los niveles).
• Se deben elegir dos archivos Jar clave (log4j-over-slf4j.jar o slf4j-log4j12.jar). Si classpath ambos, no funcionará. Si elige uno al azar, pierda las características inesperadas (por ejemplo, log4j-over-slf4j.jar no admite varios archivos de registro para las mismas clases, por ejemplo, uno para el registro de eventos y otro para el registro de datos sin formato).