Niezgodność struktury rejestrowania

Tworzę małą aplikację Java i mam nadzieję, że użyję logback do logowania.

Moja aplikacja jest zależna od starszego projektu, który rejestruje za pośrednictwem

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

... więc moim planem było użycie

org.slf4j | jcl-over-slf4j | 1.5.6

... aby przekierować logowanie JCL do

org.slf4j | slf4j-api | 1.6.0

... i ostatecznie do

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

więc moja aplikacja może logować się za pośrednictwem funkcji logowania za pośrednictwem jej interfejsu API slf4j, podczas gdy stary kod biblioteki może zalogować się do tej samej lokalizacji za pomocą przekierowania.

Niestety, to skutkuje

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ższych i niższych numerów wersji na niektórych z tych słoików, a także przekopałem się przez dokumentację API i tym podobne ... ale nie mogę znaleźć i rozwiązać problemu.

Prosimy o pomoc?

Chociaż logowanie zwrotne jest uważane za „strategiczne” ramy rejestrowania, mam pewną swobodę wyboru mechanizmu logowania, który ostatecznie wykorzystam. Mam jednak nadzieję, że użyję logback lub log4j i zdecydowanie chcę połączyć logowanie starego projektu z tym, czym się skończy „nowa” struktura logowania, poprzez wspólną konfigurację.

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

Wersje SLF4J 1.5.11 i 1.6.0 nie są kompatybilne (patrz raport zgodności ), ponieważ lista argumentów org.slf4j.spi.LocationAwareLogger.logmetody została zmieniona (dodano 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 )

Zobacz raporty zgodności dla innych wersji SLF4J na tej stronie .

Takie raporty można generować za pomocą narzędzia do sprawdzania zgodności japi .

Żeby pomóc tym, którzy są w podobnej sytuacji jak ja ...

Może to być spowodowane przypadkowym dołączeniem starej wersji slf4j w bibliotece zależnej. W moim przypadku była to tika-0.8. Zobacz https://issues.apache.org/jira/browse/TIKA-556

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

NA PRZYKŁAD.

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