java - prudent - tutorial logback




Alle Logback-Ausgaben an die Konsole unterdrücken? (7)

Also hatte ich das gleiche Problem, stellte aber fest, dass das Entfernen des falschen <layout /> -Eintrags, der irgendwo um 0.9.4 herum veraltet war, wegfiel und die Meldungen verschwunden waren ...

Ihr Appender sollte so aussehen

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

Ich habe über eine ausführlichere Beschreibung meiner Änderungen gebloggt

Wie kann ich Logback so konfigurieren, dass seine gesamte Ausgabe an die Konsole unterdrückt wird (Standardausgabe)? Insbesondere möchte ich Logbacks eigene Protokollnachrichten wie die folgenden unterdrücken (oder umleiten):

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.[email protected] - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds. 

Ich muss die gesamte Protokollierung für die Standardausgabe deaktivieren, da Anwendungen in der Produktionsumgebung keine Meldungen an die Standardausgabe drucken können.

Hinweis Ich verwende Logback 0.9.21, SLF4J 1.6.0 und unsere Anwendung wird in WebLogic 10.3.2 ausgeführt.


Dies ist eine "Ich auch" Antwort, sorry!

Glücklicherweise habe ich unten eine Lösung gefunden (siehe UPDATE).

Im Gegensatz zu einigen anderen Antworten bekomme ich einen Strom von INFO Meldungen der LogBack-Konfiguration, WARN in der Konfigurationsphase keine WARN oder WARN .

Hier sind meine Botschaften:

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.[email protected] - 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.

Hier ist meine Konfiguration:

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

Dies ist Spam, den ich nicht will, ich halte mich für unschuldig, dass ich ihn provoziert habe, und ich würde mich über etwas Hilfe freuen, wenn ich ihn beseitigen könnte.

Ein Aspekt, in dem ich möglicherweise "schuldig" bin, ist, dass ich meine Logger in einer static Variablen initialisiere. Die Dokumente empfehlen stattdessen die Verwendung von Instanzvariablen.

Versionen:

  • logback-classic-0.9.24.jar
  • logback-core-0.9.24.jar
  • slf4j-api-1.6.1.jar
  • Ausführung in einer IceFaces 2.0-App, die in Tomcat 6.0 unter Ubuntu 11.04 ausgeführt wird

AKTUALISIEREN

Endlich herausgefunden, was das Problem war!

Aus dem feinen Handbuch (und Thorbjørns Antwort ):

Wenn Sie das Debug-Attribut innerhalb des Elements festlegen, werden Statusinformationen unter der Annahme ausgegeben, dass

  1. Die Konfigurationsdatei wird gefunden
  2. Die Konfigurationsdatei ist wohlgeformtes XML.

Mein Fehler war

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

Im Nachhinein, duh! Hoffentlich helfen diese Informationen anderen.


Holger Hoffstätte hatte in seiner diagnosis Recht festgestellt, dass die doppelte Klassenpfadeintragsnachricht ein Symptom eines bug darin ist, wie Logback Klassenpfadeinträge zählt. Robert Elliot hat das Problem auch in einem thread der Logback- Benutzer-Mailingliste beschrieben . Laut Robert und anderen in dieser verwandten disussion über die SLF4J-Mailingliste disussion Logback, wenn eine Anwendung, die Logback verwendet, in einem WebLogic-Container aufgrund der Funktionsweise des WebLogic-Klassenladers ausgeführt wird, doppelte Klassenpfadeinträge für die Konfigurationsdatei logback.xml . Unabhängig davon, ob der WebLogic-Klassenlader nur eindeutige Klassenpfadeinträge melden soll oder nicht, sollte Logback sicherlich nur eindeutige Klassenpfadeinträge zählen, damit diese verwirrende, unechte Nachricht nicht gedruckt wird.

Ich habe ein bug für bug implementiert, das im Wesentlichen das tut, was Robert Elliot empfiehlt, und statt einer Liste einen Satz verwendet, um die vom Classloader zurückgegebenen Ressourcen zu speichern, wodurch doppelte Klassenpfadressourcen effektiv beseitigt werden. Ich habe den Fix erfolgreich mit Logback 0.9.24, SLF4J 1.6.1 und WebLogic 10.3.2 getestet. Wie Thorbjørn in seiner answer vorhergesagt hatte, zeigt Logback mit dieser Korrektur die Statusnachrichten für doppelte Klassenpfadeinträge (oder keine der anderen Informationsnachrichten) für die Standardausgabe mehr an.

Ich hoffe, dass die Betreuer meinen Fix in das Haupt- Repository für Logback- Quellcode integrieren und in die nächste Version einfügen .


Ich bin mit Logback nicht vertraut. Wenn jedoch auf System.out oder System.err , handelt es sich lediglich um öffentliche statische PrintStream Variablen in der System Klasse. Sie können PrintStream subclassieren und die Systemausgabevariablen auf Ihre Subclass setzen, um deren Funktionsweise zu steuern.

Zum Beispiel:

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

(Dieser Code wurde nicht getestet)


In Ihrer logback.xml ist wahrscheinlich ein Element konfiguriert. Sie können es entfernen, wenn Sie keine Konsolenaktualisierungen zum Status des Protokollierungsframeworks selbst wünschen. Das Logback-Framework empfiehlt jedoch, es zur Fehlerbehebung nicht zu deaktivieren.

Es gibt eine Alternative zum Konsolenlistener namens StatusListenerAsList, bei der die Statusmeldungen als private Liste gespeichert werden. Sie können sie bei Bedarf mit etwas Code über JMX verfügbar machen.


In meinem Fall hatte ich die "logback-test.xml" in einem abhängigen Projekt, das als Webapp-Jar bereitgestellt wurde. Die Datei "logback-test.xml" begann mit

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

Das Attribut 'scan = "true" hat diesen Fehler generiert:

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

Dies führte zu 67 (!) mehr INFO-Zeilen.

Durch das Entfernen des Attributs 'scan = "true" "verschwand das Logback-Protokoll vollständig.


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

Verwenden Sie einfach die NopStatusLinstener-Klasse. Dadurch wird die Selbstprotokollierung von Logback gestoppt.







logback