Niezgodność w zakresie rejestrowania w logach

108

Buduję małą aplikację Java i mam nadzieję, że użyję funkcji logowania do rejestrowania.Niezgodność w zakresie rejestrowania w logach

Moja aplikacja ma zależność od starszego projektu, który dokłada wszelkich rejestrowanie poprzez

org.apache.commons | com.springsource.org.apache.commons.logging | 1.1.1

... więc mój plan był do korzystania

org.slf4j | jcl-over-slf4j | 1.5.6

... aby przekierować JCL zalogowaniu do

org.slf4j | slf4j-api | 1.6.0

... i ostatecznie

ch.qos.logback | logback-classic | 0.9.22 
ch.qos.logback | logback-core | 0.9.22

dzięki czemu moja aplikacja może logować się poprzez funkcję logback za pośrednictwem swojego slf4j API, podczas gdy stary kod biblioteki może zalogować się do tej samej lokalizacji przez przekierowanie.

Niestety, powoduje to

java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V 
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:141)

Próbowałem wyższe i niższe numery verision na niektóre z tych słoików, a także poprzez kopanie dokumentacji API i takie tam ... ale jestem w stanie znaleźć i rozwiązać problem.

Pomoc, proszę?

Mimo że logback jest uważany za "strategiczny" framework rejestrowania, mam pewne pole manewru, w którym ostatecznie korzystam z mechanizmu logowania. Mam jednak nadzieję, że użyję logback lub log4j i zdecydowanie chcę połączyć logowanie starego projektu z tym, co "nowy" szkielet logowania kończy się, za pośrednictwem wspólnej konfiguracji.

Źródło

2010-08-19 Carl Smotricz

110

Mieszacie wersję 1.5.6 mostu jcl z wersją 1.5.0 slf4j-api; to nie zadziała z powodu kilku zmian w 1.6.0. Używaj tych samych wersji dla obu, tj. 1.6.1 (najnowsze). Cały czas używam mostu jcl-over-slf4j i działa dobrze.

Źródło

2010-08-20 07:06:58

Zadziałało od razu, oczywiście; Dziękuję Ci bardzo! Nie użyłem 1.6.1 tych słoików, ponieważ nie wydają się być dostępne. Jestem bardzo zirytowany na m2eclipse, który rzekomo pokazuje mi wszystkie dostępne wersje, ale w tajemniczy sposób opuszcza znaczną ich liczbę. –

W interesie kogokolwiek innego: na końcu znalazłem czerwoną strzałkę na wykresie zależności, ponieważ nawet najnowszy rdzeń logback kładzie nacisk na slf4j-1.6.0. Trochę więcej kręciło się z wersjami, aż zniknęły wszystkie czerwone strzałki, ale teraz działa zarówno jak i wszystkie niebieskie strzałki. –

Jak dokładnie to robię. – user1721803

Wystarczy, aby pomóc osobom w podobnej sytuacji do siebie ...

Może to być spowodowane, gdy biblioteka zależna przypadkowo powiązane starą wersję slf4j. W moim przypadku było to tika-0.8. Patrz: https://issues.apache.org/jira/browse/TIKA-556

Praca polega na wykluczeniu komponentu, a następnie ręcznym uzależnieniu od poprawnej lub poprawionej wersji.

EG.

<dependency> 
     <groupId>org.apache.tika</groupId> 
     <artifactId>tika-parsers</artifactId> 
     <version>0.8</version> 
     <exclusions> 
      <exclusion> 
       <!-- NOTE: Version 4.2 has bundled slf4j --> 
       <groupId>edu.ucar</groupId> 
       <artifactId>netcdf</artifactId> 
      </exclusion> 
     </exclusions> 
    </dependency> 
    <dependency> 
     <!-- Patched version 4.2-min does not bundle slf4j --> 
     <groupId>edu.ucar</groupId> 
     <artifactId>netcdf</artifactId> 
     <version>4.2-min</version> 
    </dependency>

Źródło

2010-12-01 04:43:33

Dzięki! Uderzyło mnie to, próbując użyć Jackrabbit 2.2.5 z SLF4J 1.6.1 i Logback 0.9.28! –

Dzięki. Połączyłem się z twoją odpowiedzią tutaj: http://spring-java-ee.blogspot.com/2011/04/using-jackrabbit-jcr-225-with-slf4j-161.html –

slf4j 1.5.11 i 1.6.0 wersje nie są kompatybilne (patrz compatibility report), ponieważ lista argument org.slf4j.spi.LocationAwareLogger.log metoda została zmieniona (dodana Object [] P5):

SLF4J 1.5.11:

LocationAwareLogger.log (org.slf4j.Marker p1, String p2, int p3, 
          String p4, Throwable p5)

SLF4J 1.6.0:

LocationAwareLogger.log (org.slf4j.Marker p1, String p2, int p3, 
          String p4, Object[] p5, Throwable p6)

raporty See zgodnością fo r inne wersje SLF4J on this page.

Możesz wygenerować takie raporty za pomocą narzędzia japi-compliance-checker.

Źródło

2011-04-16 17:56:14 aponomarenko

Niezgodność w zakresie rejestrowania w logach

Odpowiedz

Powiązane problemy