No hay salida de Log4J en sbt cuando se usa scalatest

Question

Estoy usando Log4J para iniciar sesión en SBT. En un archivo de configuración, he definido el nivel TRACE para el nodo raíz. Cuando ejecuto el proyecto (sbt run), todos los resultados de depuración se muestran correctamente. Pero cuando ejecuto las pruebas (sbt test), no se genera ninguna salida. Necesito insertar la clase en la configuración para ver la salida.

Las pruebas están escritas en un estilo JUnit. La ejecución de las pruebas con Eclipse muestra toda la salida de Log4J. Por lo tanto, parece ser un problema con SBT o scalatest.

configuración Log4J:

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

Cuando uso esta versión del archivo de configuración, las pruebas de compile.Compiler no generan ninguna salida del registro a menos que elimine el comentario de su nodo en la configuración Log4J. En el fichero de configuración SBT, estas dependencias se definen para compile.Compiler: (Esto es sólo un ejemplo mínimo.)

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

¿Alguien tiene una idea de por qué sucede esto y cómo detenerlo?

Answer 1

(Por desgracia he perdido mi cuenta que registró esta pregunta. :-(Pero esto es también una especie de respuesta.)

Otras investigaciones mostraron que en algún momento en el nivel de código para el compile.Compiler registrador se ha establecido manualmente a INFO. Cuando elimino esta declaración, todo funciona bien.

Lo sorprendente de esto es que establecer el nivel en una prueba también hace que todas las pruebas siguientes adopten ese nivel de registro. Esto era difícil de entender porque pensé el archivo de configuración se recargó con cada nueva prueba.

Sin embargo, después de la navegación de documentación, descubrí que la configuración real no se restablece al cargar un archivo de configuración. Para tener este comportamiento, se debe ejecutar un BasicConfigurator.resetConfiguration() antes de cargar la configuración. Con esto, todo funciona como se espera.