Supprimer toutes les sorties de consignation sur la console?

Question

Comment configurer Logback pour qu'il supprime toutes ses sorties sur la console (sortie standard)? En particulier, je souhaite supprimer (ou rediriger) les propres messages du journal Logback, tels que les suivants:

 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. 
 

Je dois désactiver toute la journalisation sur la sortie standard car notre environnement de production interdit aux applications d'imprimer des messages sur la sortie standard.

Remarque J'utilise Logback 0.9.21, SLF4J 1.6.0 et notre application s'exécute dans WebLogic 10.3.2.

Answer 1

Ces messages ne s'affiche que si au moins une des conditions suivantes est remplie:

• vous avez le débogage activé dans le logback.xml fichier
• vous avez une erreur dans votre configuration. C'est le cas ici - logback se plaint de plusieurs fichiers de configuration trouvés.
• il y a un problème de classpath si votre environnement de conflit de fichiers. (il m'est arrivé hier et a été la véritable cause de cette question).

Corriger le problème et ces messages devraient disparaître.

Answer 2

Holger Hoffstätte était correcte dans son diagnostic que le duplicata classpath message est un symptôme d'un bug dans la façon dont Logback compte classpath entrées. Robert Elliot également caractérisé le problème dans un thread sur le Logback utilisateur liste de diffusion. Selon Robert et les autres dans cette disussion sur le SLF4J liste de diffusion, lorsqu'une application qui utilise Logback s'exécute dans un WebLogic conteneur, en raison de la façon dont le WebLogic chargeur de classe fonctionne, Logback rapports en double classpath entrées pour l' logback.xml le fichier de configuration. Toutefois, peu importe si le WebLogic chargeur de classe devrait ou ne devrait pas rapport unique classpath entrées, Logback doit certainement compter seulement unique classpath entrées de sorte qu'il n'a pas l'impression de cette confusion, à de fausses message.

J'ai mis en place un correctif pour LBCLASSIC-159 qui fait essentiellement de ce que Robert Elliot recommande et utilise un ensemble au lieu d'une liste de tenir les ressources que le chargeur de classe renvoie, de manière efficace d'éliminer tous les doublons de classpath ressources. J'ai testé avec succès le fixer avec Logback 0.9.24, SLF4J 1.6.1, et WebLogic 10.3.2. Comme Thorbjørn prédit dans sa réponse, avec ce correctif en place, Logback n'affiche plus la double entrée de classpath messages d'état (ou l'un des autres messages d'information) sur la sortie standard.

J'espère que les développeurs vont intégrer mon correctif dans le principal Logback référentiel de code source et de les inclure dans la prochaine version.

Answer 3

C'est un "moi aussi" en réponse, désolé!

Heureusement, j'ai trouvé une solution (voir mise à JOUR) ci-dessous.

Contrairement à certaines autres réponses, je vais avoir un flux de LogBack de configuration INFO des messages en dépit de ne pas avoir de ERRORs ou WARNs dans la phase de configuration.

Voici mes messages:

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.

Voici ma configuration:

<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>

C'est du spam, je ne veux pas, je me considère comme innocent d'avoir provoqué, et j'apprécierais un peu d'aide pour se débarrasser d'elle.

Un respect dont je suis peut-être "coupable", c'est que je suis de l'initialisation de mon bûcherons dans un static variable; les docs vous recommandons d'utiliser les variables d'instance à la place.

Versions:

• logback-classic-0.9.24.jar
• logback-core-0.9.24.jar
• slf4j-api-1.6.1.jar
• en cours d'exécution dans un IceFaces 2.0 application qui s'exécute dans Tomcat 6.0 sous Ubuntu 11.04

---

Mise à JOUR

Enfin compris quel était le problème!

À partir de la documentation (et Thorbjørn de la réponse):

Réglage de l'attribut de débogage à l'intérieur de l'élément de sortie de statut de l'information, sous l'hypothèse que

1. le fichier de configuration se trouve
2. le fichier de configuration XML bien formé.

Mon erreur a été

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

Rétrospectivement, duh! J'espère que ces informations vont aider les autres.

Answer 4

Alors j'ai eu le même problème, mais constaté que la suppression de la incorrect <layout /> entrée qui a été déprécié de quelque part autour 0.9.4 et les messages s'en alla...

Vous appender devrait ressembler à quelque chose comme

<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>

J'ai blogué sur un plus complet description de ce que j'ai changé ce qui a fonctionné pour moi

Answer 5

Je ne suis pas familier avec Logback. Mais si vous imprimez sur System.out ou System.err , ce sont simplement des variables publiques statiques PrintStream de la classe System . Vous pouvez sous-classer PrintStream et définir les variables de sortie système dans votre sous-classe, contrôlant ainsi son fonctionnement.

Par exemple:

 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
    }
}
 

(Ce code n'est pas testé)