Нет вывода Log4J в sbt при использовании scalatest

Я использую Log4J для входа в SBT. В файле конфигурации я определил уровень TRACE для корневого узла. Когда я запускаю проект (sbt run), все выходные данные отладки отображаются правильно. Но когда я запускаю тесты (sbt test), вывод вообще не генерируется. Мне нужно вставить класс в конфигурацию, чтобы увидеть результат.

Тест написан в стиле JUnit. Выполнение тестов с помощью Eclipse показывает все выходные данные Log4J. Итак, похоже, проблема с SBT или scalatest.

Конфигурация 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>

Когда я использую эту версию файла конфигурации, тесты compile.Compiler не генерируют никаких выходных данных журнала, если я не раскомментирую его узел в конфигурации Log4J. В файле конфигурации SBT эти зависимости определены для compile.Compiler: (Это всего лишь минимальный пример.)

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

Кто-нибудь знает, почему это происходит и как это остановить?


person Michael Reinhardt    schedule 12.09.2011    source источник
comment
Если вы попытаетесь войти в консоль sbt (sbt), затем запустите тесты (test) и немедленно попробуйте last test, покажет ли это вывод?   -  person Daniel C. Sobral    schedule 14.09.2011


Ответы (1)


(К сожалению, я потерял свой аккаунт, в котором был опубликован этот вопрос. :-( Но это тоже своего рода ответ.)

Дальнейшие исследования показали, что в какой-то момент кода уровень регистратора compile.Compiler был вручную установлен на INFO. Когда я удаляю это утверждение, все работает нормально.

Удивительный факт заключается в том, что установка уровня в одном тесте также приводит к тому, что все последующие тесты принимают этот уровень ведения журнала. Это было трудно понять, потому что я думал, что файл конфигурации перезагружается с каждым новым тестом.

Однако после некоторого просмотра документации я обнаружил, что фактическая конфигурация не сбрасывается при загрузке файла конфигурации. Чтобы иметь такое поведение, перед загрузкой конфигурации необходимо выполнить BasicConfigurator.resetConfiguration(). При этом все работает как положено.

person Michael Reinhardt    schedule 14.09.2011