2011-09-12 13 views
5

Sto utilizzando Log4J per l'accesso a SBT. In un file di configurazione, ho definito il livello TRACE per il nodo radice. Quando eseguo il progetto (sbt run), tutti gli output di debug sono visualizzati correttamente. Ma quando eseguo i test (sbt test), non viene generato alcun output. Devo inserire la classe nella configurazione per vedere l'output.Nessun output Log4J in sbt quando si utilizza lo scalatest

Il test è scritto in uno stile JUnit. L'esecuzione dei test con Eclipse mostra tutti gli output di Log4J. Quindi, sembra essere un problema con SBT o scalatest.

Log4J Configurazione:

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 

<log4j:configuration debug="false" xmlns:log4j="http://jakarta.apache.org/log4j/"> 

    <appender name="stdout" class="org.apache.log4j.ConsoleAppender"> 
    <layout class="org.apache.log4j.EnhancedPatternLayout"> 
     <param name="ConversionPattern" value="%-5r [%-5p] %c: %M - %m%n"/> 
    </layout> 
    </appender> 

    <appender name="asyncApp" class="org.apache.log4j.AsyncAppender"> 
    <appender-ref ref="fileApp"/> 
    </appender> 

    <appender name="fileApp" class="org.apache.log4j.FileAppender"> 
    <param name="File" value="testlog_Compiler"/> 
    <param name="Append" value="true" /> 
    <param name="Threshold" value="ALL"/> 
    <layout class="org.apache.log4j.EnhancedPatternLayout"> 
     <param name="ConversionPattern" value="%d [%-5p] %c: %M - %m%n"/> 
    </layout> 
    </appender> 

    <appender name="fileAppTest" class="org.apache.log4j.FileAppender"> 
    <param name="File" value="testlog_Tests"/> 
    <param name="Append" value="true" /> 
    <param name="Threshold" value="ALL"/> 
    <layout class="org.apache.log4j.EnhancedPatternLayout"> 
     <param name="ConversionPattern" value="%d [%-5p] %c: %M - %m%n"/> 
    </layout> 
    </appender> 

    <logger name="main.Main$" additivity="true"> 
    <level value="INFO" /> 
    </logger> 
<!-- 
    <logger name="compile.Compiler" additivity="true"> 
    <level value="DEBUG" /> 
    </logger> 
--> 
    <logger name="test" additivity="false"> 
    <level value="TRACE" /> 
    <appender-ref ref="stdout"/> 
    <appender-ref ref="fileAppTest"/> 
    </logger> 

    <root> 
    <priority value="TRACE"/> 
    <appender-ref ref="asyncApp"/> 
    <appender-ref ref="stdout"/> 
    </root> 

</log4j:configuration> 

Quando uso questa versione del file di configurazione, le prove di compile.Compiler non genera alcun output di registro a meno che io rimuovere il commento il suo nodo nella configurazione Log4J. Nel file di configurazione SBT, queste dipendenze sono definiti per compile.Compiler: (Questo è solo un esempio minimo.)

class Comp2011ParentProject(info: ProjectInfo) extends DefaultProject(info) { 
    val compiler = project("compile", "compile", new Compile(_)) 
    class compiler(info: ProjectInfo) extends DefaultProject(info) with Eclipsify { 
     val scalatest = "org.scalatest" % "scalatest_2.9.0" % "1.6.1" 
     val junitInterface = "com.novocode" % "junit-interface" % "0.6" % "test->default" 
     val log4j = "log4j" % "log4j" % "1.2.16" 
     val log4jExtras = "log4j" % "apache-log4j-extras" % "1.1" 
    } 
} 

Qualcuno ha un indizio perché questo accade e come fermarlo?

+0

Se si tenta di immettere sbt console ('sbt'), quindi eseguire i test (' test'), e _immediatelly_ provare 'ultimo test', mostra l'output? –

risposta

0

(Purtroppo ho perso il mio conto che ha registrato questa domanda. :-(ma questo è anche un qualche tipo di risposta.)

Ulteriori ricerche hanno dimostrato che ad un certo punto nel codice del livello per il compile.Compiler logger è stato impostato manualmente a INFO. Quando elimino questa istruzione, tutto funziona correttamente

Il fatto sorprendente di questo è che l'impostazione del livello in un test fa sì che tutti i seguenti test adottino quel livello di registrazione. Questo è stato difficile da capire perché ho pensato il file di configurazione è stato ricaricato con ogni nuovo test.

Tuttavia, dopo un po 'di navigazione della documentazione, ho scoperto che la configurazione effettiva non viene ripristinata quando si carica un file di configurazione. Per avere questo comportamento è necessario eseguire BasicConfigurator.resetConfiguration() prima di caricare la configurazione. Con questo, tutto funziona come previsto.

Problemi correlati