2013-07-03 8 views
7

Mam problem z logback. Ustawiłem go (używając programu maven) i wszystko wydaje się w porządku, poza tym, że Logback zgłasza, że ​​nie może znaleźć pliku konfiguracyjnego (ale jestem w stanie zalogować się do konsoli przy użyciu domyślnej konfiguracji rejestratora).Logback nie może znaleźć logback.xml, mimo że istnieje (w ścieżce klasy)

[# | 2013-07-03T07: 55: 30,843 + 0200 | INFORMACJE | glassfish3.1.2 | javax.enterprise.system.std.com.sun.enterprise.server.logging | _ThreadID = 124; _ThreadName = Thread-2; | 07: 54: 39,844 | -INFO in ch.qos.logback.classic.LoggerContext [default] - NIE MOŻNA znaleźć zasobu [logback.groovy]

07: 54: 39,844 | -INFO in ch.qos.logback.classic.LoggerContext [default] - NIE MOŻNA znaleźć zasobu [logback-test.xml]

07: 54: 39,844 | -INFO w ch.qos.logback.classic.LoggerContext [domyślnie] - Nie można znaleźć zasobu [logback.xml]

07: 54: 39,847 | -INFO in ch.qos.logback.classic.LoggerContext [default] - Konfigurowanie domyślnej konfiguracji. | #]

umieścić plik konfiguracyjny (zwany logback.xml) do folderu src/main/resources mojego Maven artefaktu (który jest wojna). Co ciekawe, jeśli próbuję załadować config ze ścieżki klasy, uda mi:

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); 

która drukuje mój przykładowy plik konfiguracyjny:

[#|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>|#] 

Moje pom.xml posiada następujące wpisy:

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

Który jest pakowany jako plik WAR (w pliku EAR). Lokalizacja pliku logback.xml w pliku WAR wygląda następująco: WEB-INF/classes/logback.xml

Czy ktoś ma pojęcie, co jest nie tak z moją konfiguracją?

Dziękujemy za pomoc

stupidSheep

+0

Czy jesteś pewien, że używasz logbacków ze swojej wojny, a nie z serwera aplikacji? –

Odpowiedz

5

Lokalizacja w pliku WAR jest poprawna, WEB-INF/classes.

W dokumencie logback configuration documentation mówi się, gdzie plik logback.xml może znajdować się podczas wojny, ale nie wspomina nic o pliku EAR.

Czy możesz wypróbować informacje pod tym linkiem? Zastanawiam się, czy w konkretny sposób trzeba go spakować do EAR.

  1. Glassfish 3 + ear + logback.xml

(edit: drugi usunięto link, nie działa).

+0

Tak, to był literówka (poprawiłem to w pytaniu). Rozwiązanie zaproponowane w twoim pierwszym linku (Glassfish 3 + ear + logback.xml) działało !! Wielkie dzięki! Po prostu musiałem dodać nowy moduł Mavena i dodać "logback.xml" do folderu src/main/resources. Następnie musiałem dodać nowo utworzony moduł maven jako zależność od kompilacji do mojego modułu WAR. To wystarczy! Drugi link nie działał dla mnie (mimo że utworzyłem pliki MANIFEST.MF i dodałem wpisy dotyczące ścieżki klasy, logback nadal zgłosił, że nie może znaleźć konfiguracji .. Anway, jeszcze raz wielkie dzięki! – stupidSheep

+0

witaj panią owieczkę, a dzięki za pytanie, nigdy nie myślałem o tym, gdzie powinien znajdować się logback.xml w ramach EAR, a więc teraz też wiem :) – vikingsteve

3

Logback wywołuje bardzo podobny kod do kodu w przykładzie, tj getClassLoader() getResourceAsStream ("logback .xml "). Jeśli logback nie może znaleźć logback.xml, to znaczy, że zasób nie jest widoczny dla programu ładującego klasy, który załadował klasę logback. Ten program ładujący klasy jest prawdopodobnie inny niż program ładujący klasy, który załadował twój kod testowy, który może znaleźć logback.xml.

+0

Hm, nie wiem zbyt wiele o tym, jak działają ładowarki klasowe. Ale za każdym razem (raz podczas uruchamiania, raz po wdrożeniu) kod został wykonany wewnątrz kontenera (GlassFish 3). Raz był podczas uruchamiania/wdrażania pliku EAR, drugi raz, gdy aplikacja została załadowana (przez JSF @ManagedBean - w tej samej klasie, w której użyłem programu rejestrującego). Anway, obejście z dodatkowym plikiem jar działało (zobacz zaakceptowaną odpowiedź). Dzięki i tak! – stupidSheep

Powiązane problemy