web-dev-qa-db-fra.com

Supprimer toutes les sorties Logback sur la console?

Comment puis-je configurer Logback pour supprimer toute sa sortie vers la console (sortie standard)? En particulier, je souhaite supprimer (ou rediriger) les propres messages de journal de 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.

javaconfigurationlogback
52
Derek Mahar

Holger Hoffstätte avait raison dans son diagnostic que le message d'entrée de chemin de classe en double est un symptôme d'un bug dans la façon dont Logback compte les entrées de chemin de classe. Robert Elliot a également caractérisé le problème dans un thread sur la Logback liste de diffusion des utilisateurs . Selon Robert et d'autres dans ce sujet disussion sur la liste de diffusion SLF4J, lorsqu'une application qui utilise Logback s'exécute dans un conteneur WebLogic, en raison du fonctionnement du chargeur de classes WebLogic, Logback signale des entrées de chemin de classe en double pour le logback.xml fichier de configuration. Cependant, indépendamment du fait que le chargeur de classe WebLogic doive ou non signaler uniquement les entrées de chemin de classe uniques, Logback ne doit certainement compter que les entrées de chemin de classe uniques afin qu'il n'imprime pas ce message déroutant et parasite.

J'ai implémenté un correctif pour LBCLASSIC-159 qui fait essentiellement ce que Robert Elliot recommande et utilise un ensemble au lieu d'une liste pour contenir les ressources que le chargeur de classe renvoie, éliminant efficacement tout ressources de chemin de classe en double. J'ai testé le correctif avec succès avec Logback 0.9.24, SLF4J 1.6.1 et WebLogic 10.3.2. Comme Thorbjørn l'avait prédit dans son réponse , avec ce correctif en place, Logback n'affiche plus les messages d'état d'entrée de chemin de classe en double (ou aucun des autres messages d'information) sur la sortie standard.

J'espère que les mainteneurs intégreront mon correctif dans le Logback principal référentiel de code source et l'incluront dans la prochaine version.

16
Derek Mahar

Ces messages s'affichent uniquement si au moins l'une des conditions suivantes est vraie:

  • le débogage est activé dans le fichier logback.xml
  • vous avez une erreur dans votre configuration. C'est le cas ici - la déconnexion se plaint de plusieurs fichiers de configuration trouvés.
  • il y a un problème de chemin de classe si votre environnement fournit des fichiers en conflit. (celui-ci m'est venu à l'esprit hier et était la véritable cause de cette question).
  • (il y a un bogue dans la déconnexion - s'est produit)

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

40
Thorbjørn Ravn Andersen

Ceci est une réponse "moi aussi", désolé!

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

Contrairement à certaines des autres réponses, j'obtiens un flux de messages de configuration de LogBack INFO malgré l'absence 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 un spam que je ne veux pas, je me considère innocent de l'avoir provoqué, et j'apprécierais un peu d'aide pour m'en débarrasser.

Un aspect dans lequel je peux être "coupable" est que j'initialise mes enregistreurs dans une variable static; les documents recommandent plutôt d'utiliser des variables d'instance.

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 exécutée dans Tomcat 6.0 sous Ubuntu 11.04

[~ # ~] mise à jour [~ # ~]

Enfin compris quel était le problème!

De le beau manuel (et réponse de Thorbjørn ):

La définition de l'attribut de débogage dans l'élément produira des informations d'état, en supposant que

  1. le fichier de configuration est trouvé
  2. le fichier de configuration est un XML bien formé.

Mon erreur était

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

Rétrospectivement, duh ! Espérons que ces informations aideront les autres.

15
Carl Smotricz

J'ai donc eu le même problème mais j'ai constaté que la suppression de l'entrée <layout /> incorrecte qui était obsolète autour de 0.9.4 et que les messages étaient partis ...

Votre appender devrait ressembler à quelque chose

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

8
Michael McCallum

Je ne connais pas Logback. Mais s'il imprime vers System.out ou System.err, il s'agit simplement de variables publiques statiques PrintStream dans la classe System. Vous pouvez sous-classe PrintStream et définir les variables de sortie système sur 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é)

3
Brian S

En fait, le fait que le même emplacement logback.xml soit signalé plusieurs fois ressemble plus à un bogue dans logback qu'autre chose. Soit le signaler au JIRA de déconnexion ( ici ), soit vérifier d'abord si le bocal en question se trouve plusieurs fois sur le chemin de classe.

2
Holger Hoffstätte

Dans mon cas, j'avais le "logback-test.xml" dans un projet dépendant qui était déployé en tant que pot d'application Web. Le fichier "logback-test.xml" a commencé avec

<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

ce qui a donné lieu à 67 (!) lignes INFO supplémentaires.

En supprimant l'attribut 'scan = "true"', le journal de journalisation a complètement disparu.

2
xtian

Vous avez très probablement un élément configuré dans votre logback.xml. Vous pouvez le supprimer si vous ne souhaitez pas de mises à jour de la console sur l'état de l'infrastructure de journalisation elle-même. Cependant, le cadre de déconnexion recommande de ne pas le désactiver à des fins de dépannage.

Il existe une alternative à l'écouteur de console appelée 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.

1
baja

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é cela dans logback news , mais c'était vraiment difficile à trouver.

Si vous souhaitez supprimer ce message, vous devez configurer outputPatternAsPresentationHeader sur 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>
1
Betlista
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
</configuration>

Utilisez simplement la classe NopStatusLinstener et cela arrêtera la journalisation automatique de la déconnexion.

1
Rupesh Kumar