Logger slf4j ist die logback konfiguriert Ebene nicht mit

Question

Auch wenn ich die Gaben unter dem für die Benutzer vergeben haben, müssen zu helfen versucht, bleibt die ursprüngliche Frage unbeantwortet. Es existiert keine tatsächliche Workable-Lösung, um sicherzustellen, dass die logback.groovy-konfigurierte Protokollierung innerhalb der Junit-Tests geehrt wird. Die Tests laden die logback config und es meldet das richtige Niveau und dennoch die eigentliche Testprotokollierung (ausschließlich durch slf4j) jeden oder TRACE Ebene

Ich weiß, andere haben das gleiche Problem festgestellt und es ist sehr ärgerlich, wenn Tests für große Projekte viel länger dauern aufgrund der Konsole Protokollierung viel zu ausführlich. Ich kann nicht werfen Bounties um diese Frage. Ich hoffe, jemand kommt mit einer guten Lösung, die ermöglicht die Testprotokollierung ordnungsgemäß auf verschiedenen Ebenen über eine Systemeigenschaft konfiguriert werden. Für das Projekt können dann verschiedene Konfigurationen erstellt werden, sodass Tests auf unterschiedlichen Protokollierungsschwellenwerten konfiguriert werden können.

Meine Protokollierung wird durch logback durch eine logback.groovy Datei konfiguriert

Nun, wenn mein Maven POM Projekt, das alle anderen Projekte Aggregate gestartet wird, sie die ganze Eigenschaft System übergibt die richtige Protokollstufe einzustellen.

Wenn jedoch die Junit-Tests ausgeführt werden, nimmt der Logger aus irgendeinem Grund nicht die korrekte Stufe an, obwohl die statischen @beforeClass-Testklassen sicherstellen, dass das Logback ordnungsgemäß konfiguriert ist.

Es ist nicht die Logger in den Tests, die das Problem sind, - ja - ja sie auch--, das eigentliche Problem ist, dass die Logger in den Code-Abschnitten, die (alle meine Programme Logger überall) laufen auf die falsche Protokollierungsstufe. Sie erfassen nicht, was die Protokollierung ist, wenn die Programmtests konfiguriert sind.

Die Projekte melden jedoch das korrekte Protokoll, wenn das Logback mit der logback.goovy-Datei initialisiert wird. Die aktuelle Protokollierungsstufe wird jedoch auf TRACE oder ALL gesetzt.

Aus der folgenden Ausgabe ist ersichtlich, dass Logback auf INFO konfiguriert wurde. Aber die erste Projektprotokollierungsanweisung bei TRACE (letzte Zeile) zeigt, dass sie nicht abgeholt wird.

Hilfe.

------------------------------------------------------- 
T E S T S 
------------------------------------------------------- 
Running groovy.text.StreamingTemplateEngineTest 
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.245 sec 
Running net.abcd.templating.InlinerTest 
01:22:15,265 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Added status listener of type [ch.qos.logback.core.status.OnConsoleStatusListener] 
01:22:15,290 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Setting ReconfigureOnChangeFilter scanning period to 5 minutes 
01:22:15,290 |-INFO in ReconfigureOnChangeFilter{invocationCounter=0} - Will scan for changes in [[C:\Users\ABDC\Dropbox\workspace\abcd\AbcdTemplating\conf\logback.groovy]] every 300 seconds. 
01:22:15,290 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Adding ReconfigureOnChangeFilter as a turbo filter 
01:22:15,312 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 
01:22:15,316 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Naming appender as [STDOUT] 
*********************************************************** 

LOGGING MODE PROPERTY 'net.abcd.logging.level' SET TO: [info] 
IT CAN BE SET TO: OFF, ERROR, WARN, INFO, DEBUG, TRACE, ALL, INFO 

*********************************************************** 
getLogLevel() returned 'INFO' 
01:22:15,496 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Setting level of logger [ROOT] to INFO 
01:22:15,532 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@1e8c3cb - Attaching appender named [STDOUT] to Logger[ROOT] 
01:22:15.846 [main] TRACE net.abcd.templating.Inliner - Document: 

Meine logback.groovy Datei ist:

displayStatusOnConsole() 
scan('5 minutes') // Scan for changes every 5 minutes. 
setupAppenders() 
setupLoggers() 

def displayStatusOnConsole() { 
    statusListener OnConsoleStatusListener 
} 

def setupAppenders() { 
    appender('STDOUT', ConsoleAppender) { 
     encoder(PatternLayoutEncoder) { 
      pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %-16logger{50} - %msg%n" 
     } 
    } 
} 


def setupLoggers() {  
    def loglevel = getLogLevel() 
    println("getLogLevel() returned '${loglevel}'") 
    root(loglevel, ['STDOUT']) 
} 

def getLogLevel() { 
    def mode = System.getProperty('net.abcd.logging.level', '') 
    println("***********************************************************") 
    println("") 
    println("LOGGING MODE PROPERTY 'net.abcd.logging.level' SET TO: [${mode}]") 
    println("IT CAN BE SET TO: OFF, ERROR, WARN, INFO, DEBUG, TRACE, ALL, INFO") 
    println("") 
    println("***********************************************************") 
    switch(mode.toLowerCase()){ 
    case 'off': 
     return OFF 
    case 'error': 
     return ERROR 
    case 'warn': 
     return WARN 
    case 'info': 
     return INFO 
    case 'debug': 
     return DEBUG 
    case 'trace': 
     return TRACE 
    case 'all': 
     return ALL 
    default: 
     return INFO 
    } 
} 

Answer 1

ich auch ein ähnliches Problem auf meine JUnit-Tests erfüllt. Ich konnte keine gute Lösung finden. Früher habe ich um unter Arbeit:

import ch.qos.logback.classic.Level; 
import ch.qos.logback.classic.Logger; 
import org.slf4j.LoggerFactory; 
... 
static Logger logger; 
static{ 
    // Logger.ROOT_LOGGER_NAME == "ROOT" 
    logger = ((Logger) LoggerFactory.getLogger(Logger.ROOT_LOGGER_NAME)); 
    logger.setLevel(Level.INFO); 
} 

...

ich in Ihrem Fall denken, irgendwie eine Bibliothek verwendet er eigene ConsoleAppender Instanz, deren Name ist nicht ‚STDOUT‘. Ich hoffe, Root-Log-Level sollte das Problem beheben.

root(loglevel, ['ROOT']); 

Answer 2

Normalerweise routen wir jede Protokollierung über slf4j und konfigurieren dann die Protokollierung mit Logback. Also unsere Maven Abhängigkeiten wie folgt aussehen:

<dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>slf4j-api</artifactId> 
     <version>${slf4j.version}</version> 
    </dependency> 
    <dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>jcl-over-slf4j</artifactId> 
     <version>${slf4j.version}</version> 
    </dependency> 
    <dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>log4j-over-slf4j</artifactId> 
     <version>${slf4j.version}</version> 
    </dependency> 
    <dependency> 
     <groupId>org.slf4j</groupId> 
     <artifactId>jul-to-slf4j</artifactId> 
     <version>${slf4j.version}</version> 
    </dependency> 
    <dependency> 
     <groupId>ch.qos.logback</groupId> 
     <artifactId>logback-core</artifactId> 
     <version>${logback.version}</version> 
    </dependency> 
    <dependency> 
     <groupId>ch.qos.logback</groupId> 
     <artifactId>logback-classic</artifactId> 
     <version>${logback.version}</version> 
    </dependency> 

Also, wenn einige Abhängigkeit verwendet Java-Commons-Logging (JCL), log4j oder java.util.logging (Juli) als seine Protokollierung überbrückt wird SLF4J. Die Anwendungsprotokollierung verwendet auch slf4j, und das wird dann mit Logback konfiguriert.

Sie müssen also möglicherweise eine der Brücken (wie jcl-über-slf4j) verwenden, um die Protokollierung externer Abhängigkeiten unter Kontrolle zu bekommen.

Bearbeiten: Pavel Horal, danke für den Juli, und ja, du hast Recht. Man muss etwas mehr tun als nur Abhängigkeiten hinzuzufügen. Wir haben auch einen Logback-Konfigurator, der explizit SLF4JBridgeHandler.install() aufruft. Unser Konfigurator lädt auch die Logback-Konfigurationsdatei und ich habe diesen Aufruf vergessen. Aber ich wollte hauptsächlich in die Richtung eines Problems mit mehreren Logging-Bibliotheken verweisen, die von externen Abhängigkeiten verwendet werden, und auf diese Bridges, die verschiedene Logging-Bibliotheken unter dem Dach des Logbacks platzieren können.