Supprimer toute sortie Logback sur la console?

ces messages ne s'affichent que si au moins un des éléments suivants est vrai:

• vous avez le débogage activé dans le logback.fichier xml
• 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 classpath si votre environnement fournit des fichiers contradictoires. (il m'est arrivé hier et a été la véritable cause de cette question.)
• (il y a un bug dans logback - qui s'est passé)

corriger la question et ces messages devraient disparaître.

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 reçois un flux de messages de configuration LogBack INFO malgré l'absence de ERROR s ou WARN s 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 que je ne veux pas, je me considère innocent de l'avoir provoqué, et j'apprécierais de l'aide pour m'en débarrasser.

l'un des points sur lesquels je peux être" coupable "est que j'initialise mes loggers dans une variable static ; les docs recommandent d'utiliser des variables d'instance à la place.

Versions:

• logback-classic-0.9.24.jar
• logback-core-0.9.24.jar
• slf4j-api-1.6.1.jar
• exécution dans une application IceFaces 2.0 tournant dans Tomcat 6.0 sous Ubuntu 11.04

mise à jour

a finalement compris quel était le problème!

à Partir de l'amende manuel (et Thorbjørn la réponse de ):

Définir l'attribut de débogage dans l'élément produira des informations sur l'état, en partant de l'hypothèse que

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

mon erreur était

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

En rétrospective, duh! espérons que cette information aidera les autres.

donc j'ai eu le MÊME PROBLÈME MAIS j'ai trouvé que supprimer la mauvaise entrée qui était dépréciée quelque part autour de 0.9.4 et les messages ont disparu...

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 complète description de ce que j'ai changé qui a fonctionné pour moi

Je ne suis pas familier avec Logback. Mais si c'est l'impression System.out ou System.err , ce sont simplement des variables publiques statiques PrintStream dans la classe System . Vous pouvez sous-classe PrintStream et définir les variables de sortie du système à votre sous-classe, contrôlant ainsi comment cela fonctionne.

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'a pas été testé)

dans mon cas, j'ai eu le" logback-test.xml" dans un projet dépendant qui était en cours de déploiement comme un jar webapp. Le " logback-test.xml" fichier

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

l'attribut scan= "true" 'a généré cette erreur:

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

qui a abouti à 67 (!) plus d'INFOS lignes.

en supprimant l'attribut 'scan=" true"', le logback a complètement disparu.

en fait le fait que le même logback.la localisation xml est signalée plusieurs fois semble plus ressembler à un bogue dans logback qu'à toute autre chose. Signalez ceci à la JIRA de retour ( ici ) ou vérifiez d'abord si le bocal en question Est sur le chemin de classe plusieurs fois.

Vous avez probablement un élément configuré dans votre logback.XML. Vous pouvez le supprimer, si vous ne voulez pas de mises à jour de la console sur l'état du framework de journalisation lui-même. Cependant, logback framework recommande de ne pas le désactiver pour des raisons de dépannage.

il existe une alternative à L'écouteur de la console appelé StatusListenerAsList qui conserve les messages d'état en tant que liste privée. Vous pouvez l'exposer via JMX, si nécessaire, avec un peu de code.

je veux juste ajouter des informations sur le message d'en-tête par défaut ajouté dans logback 1.0.2:

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

j'ai trouvé que dans logback news , mais il était vraiment difficile de trouver.

si vous souhaitez supprimer ce message, vous devez configurer outputPatternAsPresentationHeader à false:

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

utilisez simplement la classe NopStatusLinstener et cela arrêtera l'auto-journalisation de logback.