¿Qué pasa con el registro en Java? [cerrado]

¿Por qué uno usaría uno de los siguientes paquetes en lugar del otro?

• Registro de Java
• Registro de bienes comunes
• Log4j
• SLF4j
• Volver a iniciar sesión

En orden cronológico de aparición de api (hasta donde yo sé):

• Log4j porque casi todo el mundo lo usa (en mi experiencia)
• Commons Logging porque los proyectos de código abierto lo usan (para que puedan integrarse con cualquier marco de registro que se use en la solución integrada); especialmente válido si eres un API / Framework / OSS y confías en otros paquetes que usan Commons Logging.
• Commons Logging porque no quiere "bloquearse" en un marco de registro en particular (así que, en su lugar, se limita a lo que Commons Logging le brinda); no creo que sea sensato decidir usar este punto como razón.
• Registro de Java porque no desea agregar un frasco adicional.
• SLF4j porque es más nuevo que Commons Logging y proporciona registro parametrizado:

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback porque es más nuevo que log4j y, nuevamente, admite el registro parametrizado, ya que implementa SLF4j directamente
• SLF4j / Logback porque está escrito por el mismo tipo que hizo log4j, por lo que lo ha mejorado (según Ken G , gracias. Parece encajar al mirar sus publicaciones de noticias anteriores )
• SLF4j porque también publican un adaptador log4j para que no tenga que "cambiar" log4j en un código anterior, simplemente haga que log4j.properties use SLF4j y su configuración

Encuentro que iniciar sesión en Java es confuso, inconsistente, mal documentado y, especialmente, desordenado. Además, existe una gran similitud entre estos marcos de registro, lo que resulta en la duplicación de esfuerzos y la confusión en cuanto al entorno de registro en el que se encuentra. En particular, si está trabajando en una pila de aplicaciones web Java seria, a menudo se encuentra en múltipleentornos de registro a la vez; (por ejemplo, hibernate puede usar log4j y tomcat java.util.logging). Apache commons está destinado a unir diferentes marcos de registro, pero en realidad solo agrega más complejidad. Si no sabe esto de antemano, es completamente desconcertante. ¿Por qué mis mensajes de registro no se imprimen en la consola, etc.? Ohh, porque estoy mirando los registros de Tomcat y no log4j. Añadiendo otra capa de complejidad, el servidor de aplicaciones puede tener configuraciones de registro global que pueden no reconocer las configuraciones locales para una aplicación web en particular. Por último, todos estos marcos de registro son DEMASIADO COMPLICADOS. Iniciar sesión en Java ha sido un desastre desorganizado que ha dejado a los desarrolladores como yo frustrados y confundidos.

Las primeras versiones de Java no tenían un marco de registro integrado que condujera a este escenario.

Hay un punto importante que no se mencionó antes:

SLF4J (y tanto Logback como LOG4J como backend de registro) tienen soporte para un contexto de diagnóstico mapeado (MDC, consulte javadoc y documentación ).

Esto es esencialmente un mapa <String, String> local de subproceso que puede usar para agregar información de contexto adicional a su evento de registro. El estado actual del MDC se adjunta a cada evento.

Esto puede ser increíblemente útil si pones cosas como el nombre de usuario y la URL de la solicitud (en el caso de una aplicación web). Esto se puede hacer automáticamente usando un filtro, por ejemplo.

Consulte también las respuestas a la pregunta ¿Cuáles son las mejores prácticas para registrar un error? , especialmente:

• Hay algunos problemas potenciales de carga de clases con Commons Logging.

• Log4J y SLF4J fueron desarrollados por la misma persona, aprendiendo de los problemas encontrados en la práctica con Log4J.

En el proyecto de nuestra empresa usamos LOG4j y es muy fácil de usar como lo mostró Stephen en su ejemplo. También hemos escrito nuestras propias clases de patrones para LOG4j para que pueda crear sus propios esquemas de archivos de salida. Puede describir cómo debería verse su archivo de registro. Es posible mejorar las clases log4j originales.

Puede cambiar todas las propiedades de LOG4j en un archivo log4j.properties, por lo que puede usar diferentes archivos para diferentes proyectos.

El registro de Java no es mi favorito, pero esto podría deberse a que uso log4j desde el principio.

La descripción general de Commons Logging da la razón de su existencia: registro desde el código de la biblioteca, cuando no tiene control sobre el marco de registro subyacente. Muy importante para los diversos proyectos de Apache, que estarán vinculados a aplicaciones externas. Quizás no sea tan importante para los proyectos de TI internos, donde tiene el control total.

Dicho esto, escribo a Commons Logging, al igual que muchos de los otros desarrolladores que conozco. La razón es minimizar el bagaje mental: puede cambiar de proyecto o trabajo, y no tener que aprender un nuevo marco (siempre que el nuevo trabajo / proyecto también use CL, y / o pueda convencerlos de que se muden a él).

Además, es valioso crear sus propios contenedores en torno a cualquier marco que utilice. Como se describe aquí , me gusta usar un objeto LogWrapper para proporcionar una cadena personalizada (importante) y minimizar el desorden visual de las declaraciones de registro (menos importante).

Generalmente, usaría Log4J por defecto.

Usaría Java Logging si no me importara una dependencia en Java 1.4, pero aún usaría Log4J de preferencia.

Usaría Commons Logging si estuviera mejorando algo que ya lo usaba.

Sugeriría crear una fachada de registro delgada que pueda escribir en cualquiera de los marcos de registro, momento en el que la elección del motor de respaldo se convierte en un punto discutible.