2013-07-03 1 views
7

У меня проблема с logback. Я установил его (используя maven), и все кажется прекрасным, за исключением того, что отчеты журнала не могут найти файл конфигурации (но я могу войти в консоль, используя конфигурацию регистратора по умолчанию).Logback не может найти logback.xml, хотя он существует (по пути к классам)

[# | 2013-07-03T07: 55: 30,843 + 0200 | INFO | glassfish3.1.2 | javax.enterprise.system.std.com.sun.enterprise.server.logging | _ThreadID = 124; _ThreadName = Thread-2; | | | | | | | | | | | | | | | | | | | | ch.qos.logback.classic.LoggerContext [default] - Не удалось найти ресурс [logback-test.xml]

07: 54: 39,844 | -INFO в ch.qos.logback.classic.LoggerContext [по умолчанию] - Не удалось найти ресурс [logback.xml]

07: 54: 39,847 | -INFO в ch.qos.logback.classic.LoggerContext [по умолчанию] - настройка конфигурации по умолчанию. | #]

Я положил конфигурационный файл (называется logback.xml) в src/main/resources папку моего Maven артефакта (который является WAR). Интересно, если я пытаюсь загрузить конфиг из пути к классам, мне удастся:

Reader r = new InputStreamReader(getClass().getClassLoader().getResourceAsStream("logback.xml")); 
StringWriter sw = new StringWriter(); 
char[] buffer = new char[1024]; 
for (int n; (n = r.read(buffer)) != -1;) 
    sw.write(buffer, 0, n); 
String str = sw.toString(); 
System.out.println(str); 

который печатает мой конфигурационный файл примера:

[#|2013-07-03T07:55:30.844+0200|INFO|glassfish3.1.2|javax.enterprise.system.std.com.sun.enterprise.server.logging|_ThreadID=124;_ThreadName=Thread-2;|<configuration> 
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> 
     <!-- encoders are assigned the type 
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default --> 
     <encoder> 
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern> 
     </encoder> 
    </appender> 

    <root level="debug"> 
     <appender-ref ref="STDOUT" /> 
    </root> </configuration>|#] 

Мои pom.xml имеет следующие данные:

 <dependency> 
      <groupId>ch.qos.logback</groupId> 
      <artifactId>logback-classic</artifactId> 
      <version>1.0.13</version> 
     </dependency> 

     <dependency> 
      <groupId>ch.qos.logback</groupId> 
      <artifactId>logback-core</artifactId> 
      <version>1.0.13</version> 
     </dependency> 

     <dependency> 
      <groupId>org.slf4j</groupId> 
      <artifactId>slf4j-api</artifactId> 
      <version>1.7.5</version> 
     </dependency> 

Которая упакована в виде файла WAR (внутри файла EAR). Расположение файла logback.xml внутри WAR-файла выглядит следующим образом: WEB-INF/classes/logback.xml

Есть ли у кого-нибудь идеи, что случилось с моей настройкой?

Большое спасибо за вашу помощь

stupidSheep

+0

Вы уверены, что используете logback из своей войны, а не с сервера приложений? –

ответ

5

Расположение в файле WAR является правильным, WEB-INF/classes.

logback configuration documentation рассказывает о том, где файл logback.xml может находиться в пределах войны, но в нем ничего не говорится об EAR.

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

  1. Glassfish 3 + ear + logback.xml

(редактирование: вторая ссылка удалена, не работает).

+0

Да, это была опечатка (я исправил ее в вопросе). Решение, предложенное в вашей первой ссылке (Glassfish 3 + ear + logback.xml), работало! Большое спасибо! Мне просто пришлось добавить новый модуль Maven и добавить «logback.xml» в папку src/main/resources. Затем мне пришлось добавить вновь созданный модуль maven в качестве зависимости от компиляции моего модуля WAR. Это сделал трюк! Вторая ссылка не сработала для меня (хотя я создал файлы MANIFEST.MF и добавил записи пути к классу, журнал оставил сообщение о том, что он не может найти конфигурацию. Anway, еще раз спасибо! – stupidSheep

+0

Вы приветствую госпожу овцу, и спасибо за вопрос, я никогда не думал о том, где logback.xml должен быть расположен в EAR, и теперь я тоже знаю :) – vikingsteve

3

Logback вызывает очень похожий код к коду в вашем примере, т.е. getClassLoader() getResourceAsStream ("Logback .xml "). Если logback не может найти logback.xml, то должно быть, что ресурс не отображается загрузчику классов, загружающим класс журнала. Этот загрузчик классов, скорее всего, отличается от загрузчика классов, который загрузил ваш тестовый код, который может найти logback.xml.

+0

Хм, я мало знаю о том, как работают загрузчики классов. Но оба раза (один раз во время запуска, один раз после развертывания) код выполнялся внутри контейнера (GlassFish 3). Один раз был во время запуска/развертывания файла EAR, второй раз, когда приложение было загружено (JSF @ManagedBean - в том же классе, где я использовал регистратор). Anway, обходной путь с дополнительным файлом jar работал (см. Принятый ответ). Спасибо, в любом случае! – stupidSheep

Смежные вопросы