name additivity java configuration logback

java - additivity - ¿Suprimir toda la salida de Logback a la consola?



logback file location (10)

¿Cómo puedo configurar Logback para suprimir toda su salida a la consola (salida estándar)? En particular, deseo suprimir (o redirigir) los propios mensajes de registro de Logback, como los siguientes:

16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml] 16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath. 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] 16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] 16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds.

Necesito desactivar todo el registro a la salida estándar porque nuestro entorno de producción no permite que las aplicaciones impriman ningún mensaje en la salida estándar.

Tenga en cuenta que estoy usando Logback 0.9.21, SLF4J 1.6.0, y nuestra aplicación se ejecuta en WebLogic 10.3.2.

Así que tuve el mismo problema pero descubrí que eliminar la entrada incorrecta de <layout /> que estaba obsoleta en algún lugar alrededor de 0.9.4 y los mensajes desaparecieron ...

Usted appender debe mirar algo así como

<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> <level>info</level> </filter> <encoder> <pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</pattern> </encoder> </appender>

He escrito un blog sobre una descripción más complete de lo que he cambiado que funcionó para mí

En mi caso, tenía el "logback-test.xml" en un proyecto dependiente que se estaba implementando como un jar de aplicaciones web. El archivo "logback-test.xml" comenzó con

<configuration debug="false" scan="true">

El atributo ''scan = "true"'' generó este error:

ERROR in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@716de067 - URL [jar:file:/C:/Local...cut.../WEB-INF/lib/My.Dev.jar!/logback-test.xml] is not of type file

que resultó en 67 (!) más líneas INFO.

Al eliminar el atributo ''scan = "true"'', el registro de logback desapareció por completo.

En realidad, el hecho de que la misma ubicación logback.xml se informe varias veces parece más un error en logback que otra cosa. O informa esto al logback JIRA ( here ) o primero comprueba si el jar en cuestión está en el classpath varias veces.

Esos mensajes solo se muestran si al menos uno de los siguientes es verdadero:

  • tiene la depuración habilitada en el archivo logback.xml
  • tienes un error en tu configuración Ese es el caso aquí - logback se queja de los múltiples archivos de configuración encontrados.
  • hay un problema de ruta de clase si su entorno proporciona archivos conflictivos. (este se me ocurrió ayer y fue la verdadera causa de esta pregunta).
  • (hay un error en logback - ha sucedido)

Corrija el problema y esos mensajes deberían desaparecer.

Esta es una respuesta "yo también", ¡lo siento!

Afortunadamente, he encontrado una solución (ver ACTUALIZACIÓN) a continuación.

Contrariamente a algunas de las otras respuestas, recibo una secuencia de mensajes de configuración de LogBack a pesar de no tener ERROR o WARN en la fase de configuración.

Aquí están mis mensajes:

13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy] 13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml] 13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml] 13:39:20,496 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@14e2c9c - Will scan for changes in file [/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml] every 60 seconds. 13:39:20,496 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter 13:39:20,497 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 13:39:20,501 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT] 13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property 13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack. 13:39:20,537 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG 13:39:20,537 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT] 13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [ch.qos.logback] to OFF 13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [ch.qos.logback] to false 13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.

Aquí está mi configuración:

<configuration debug="true" scan="true"> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <!-- encoders are by default assigned the type ch.qos.logback.classic.encoder.PatternLayoutEncoder --> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <root level="debug"> <appender-ref ref="STDOUT" /> </root> <logger name="ch.qos.logback" level="OFF" additivity="false" /> </configuration>

Esto es spam que no quiero, me considero inocente de haberlo provocado, y agradecería algo de ayuda para deshacerme de él.

Un aspecto en el que puedo ser "culpable" es que estoy inicializando mis registradores en una variable static ; los documentos recomiendan usar variables de instancia en su lugar.

Versiones:

  • logback-classic-0.9.24.jar
  • logback-core-0.9.24.jar
  • slf4j-api-1.6.1.jar
  • ejecutándose en una aplicación IceFaces 2.0 que se ejecuta en Tomcat 6.0 bajo Ubuntu 11.04

ACTUALIZAR

¡Finalmente descubrió cuál era el problema!

Del fino manual (y la respuesta de Thorbjørn ):

Al establecer el atributo de depuración dentro del elemento se generará información de estado, bajo la suposición de que

  1. el archivo de configuración se encuentra
  2. el archivo de configuración está bien formado XML.

Mi error fue

<configuration debug="true" scan="true">

En retrospectiva, duh! Esperamos que esta información ayude a otros.

Holger Hoffstätte tuvo razón en su diagnosis que el mensaje de entrada duplicado del classpath es un síntoma de un bug en la forma en que Logback cuenta las entradas del classpath. Robert Elliot también characterized el problema en un thread en la lista de correo del usuario de Logback. Según Robert y otros en esta disussion relacionada en la lista de correo SLF4J, cuando una aplicación que usa Logback se ejecuta en un contenedor WebLogic, debido a la forma en que funciona el cargador de clases WebLogic, Logback informa las entradas duplicadas de classpath para el archivo de configuración logback.xml . Sin embargo, independientemente de si el cargador de clases de WebLogic debe o no debe informar solo entradas de classpath únicas, Logback ciertamente debe contar solo entradas de classpath únicas para que no imprima este mensaje confuso y espurio.

Implementé una fix para bug que básicamente hace lo que Robert Elliot recomienda y usa un conjunto en lugar de una lista para contener los recursos que devuelve el cargador de clases, eliminando de manera efectiva cualquier recurso de ruta de clase duplicado. He probado con éxito la solución con Logback 0.9.24, SLF4J 1.6.1 y WebLogic 10.3.2. Como Thorbjørn predijo en su answer , con este arreglo en su lugar, Logback ya no muestra los mensajes de estado de entrada de classpath duplicados (o cualquiera de los otros mensajes informativos) a la salida estándar.

Espero que los mantenedores integren mi corrección en el repositorio principal del código fuente de Logback y lo incluyan en la próxima versión.

Lo más probable es que tenga un elemento configurado en su logback.xml. Puede eliminarlo, si no desea ninguna actualización de la consola sobre el estado de la propia estructura de registro. Sin embargo, logback framework recomienda no deshabilitarlo para la resolución de problemas.

Existe una alternativa al oyente de la consola llamada StatusListenerAsList que mantiene los mensajes de estado como una lista privada. Puede exponerlo a través de JMX, si es necesario, con un poco de código.

No estoy familiarizado con Logback. Pero si está imprimiendo en System.out o System.err , estas son simplemente variables de PrintStream estáticas PrintStream en la clase System . Podría subclase PrintStream y establecer las variables de salida del sistema para su subclase, controlando así cómo funciona.

Por ejemplo:

public class NOPPrintStream extends PrintStream { public NOPPrintStream() { super((OutputStream)null); } public void println(String s) { /* Do nothing */ } // You may or may not have to override other methods } public class MyClass { public static void main(String[] args) { System.out = new NOPPrintStream(); // Start program } }

(Este código no ha sido probado)

Solo quiero agregar información sobre el mensaje de encabezado predeterminado agregado en logback 1.0.2:

#logback.classic pattern: %d [%thread] %-5level %logger{36} - %msg%n

Lo encontré en las noticias de logback , pero fue realmente difícil de encontrar.

Si desea eliminar este mensaje, debe configurar outputPatternAsPresentationHeader en falso:

<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern> <!-- do not print pattern as a header --> <outputPatternAsPresentationHeader>false</outputPatternAsPresentationHeader> </encoder> </appender>

<configuration> <statusListener class="ch.qos.logback.core.status.NopStatusListener" /> </configuration>

Simplemente use la clase NopStatusLinstener y esto detendrá el auto registro de logback.