mvc - ¿Qué pasa con el registro en Java?

modelo vista controlador java mysql

Question

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

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

Answer 1

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 el registro de Commons.

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

Answer 2

En nuestro proyecto de empresa usamos LOG4j y es muy fácil de usar como Stephen mostró 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 ser su archivo de registro. Es posible mejorar las clases log4j originales.

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

El registro de Java no es mi favor, pero podría ser porque utilizo log4j desde el principio.

Answer 3

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

• Log4j porque la mayoría de las personas 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 utilizado en la solución integrada); especialmente válido si usted es un API / Framework / OSS y confía en otros paquetes que usan el Registro de Commons.
• Commons Logging porque no quiere "bloquear" un marco de trabajo de registro en particular (así que en su lugar se bloquea a lo que Commons Logging le da en su lugar) - No creo que sea sensato decidir usar este punto como la razón.
• Registro de Java porque no desea agregar un jar adicional.
• SLF4j porque es más reciente que Commons Logging y proporciona el 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, de nuevo, admite el registro parametrizado, ya que implementa SLF4j directamente
• SLF4j / Logback porque está escrito por el mismo tipo que lo hizo log4j, por lo que lo ha mejorado (de acuerdo con Ken G , gracias. Parece que se ajusta al mirar sus publicaciones anteriores )
• SLF4j porque también publican un adaptador log4j por lo que no tiene que "cambiar" log4j en un código anterior, solo haga que log4j.properties use SLF4j y su configuración

Answer 4

Encuentro que el inicio de sesión en Java es confuso, incoherente, poco documentado y especialmente fortuito. Además, hay una gran cantidad de similitud entre estos marcos de trabajo de registro que resulta en la duplicación de esfuerzos y la confusión en cuanto a qué entorno de registro realmente se encuentra. En particular, si está trabajando en una pila de aplicaciones web de Java seria, a menudo se encuentra múltiples entornos 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 trabajo de registro, pero en realidad solo agrega más complejidad. Si no lo sabes antes de tiempo, 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. Al agregar 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 están DEMASIADO COMPLICADOS. Iniciar sesión en Java ha sido un desastre desorganizado que deja 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.

Answer 5

Hay un punto importante que no se mencionó anteriormente:

SLF4J (y Logback y LOG4J como el backend de registro) tienen soporte para el llamado contexto de diagnóstico asignado (MDC, ver javadoc y documentation ).

Esto es esencialmente un Map-String Map <String, String> 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 coloca 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.

Answer 6

La descripción de Logging de Commons da la razón de su existencia: iniciar sesión 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 se vincularán a aplicaciones externas. Tal vez no tan importante para los proyectos internos de TI, donde tiene un control total.

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

Además, tiene algún valor crear sus propios wrappers en cualquier marco que use. Como se describe here , me gusta usar un objeto LogWrapper para proporcionar una cadena de caracteres personalizada (importante) y minimizar el desorden visual de las declaraciones de registro (menos importante).

Answer 7

Por lo general, prefiero usar Log4J.

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

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

Answer 8

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