日志框架不兼容

发布于 2024-09-14 16:35:30 字数 1023 浏览 3 评论 0原文

我正在构建一个小型 Java 应用程序,并希望使用 logback 进行日志记录。

我的应用程序依赖于一个旧项目,该项目通过

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

... 进行日志记录,因此我的计划是使用

org.slf4j | jcl-over-slf4j | 1.5.6

... 将 JCL 日志记录重定向到

org.slf4j | slf4j-api | 1.6.0

... ,最终使

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

我的应用程序可以通过其 slf4j API 通过 logback 进行日志记录,同时旧的库代码可以通过重定向登录到同一位置。

唉,这导致

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)

我在其中一些 jar 上尝试了更高和更低的版本号,并且还深入研究了 API 文档等......但我无法找到并解决问题。

请帮忙?

尽管 logback 被认为是“战略”日志框架,但我最终使用的日志机制有一些余地。不过,我希望使用 logback 或 log4j,并且我绝对希望通过通用配置将旧项目的日志记录合并到“新”日志记录框架最终的内容中。

I'm building a small Java app and hoping to use logback for logging.

My app has a dependency on an older project that does its logging via

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

...so my plan was to use

org.slf4j | jcl-over-slf4j | 1.5.6

...to redirect the JCL logging to

org.slf4j | slf4j-api | 1.6.0

...and ultimately to

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

so my app can log through logback via its slf4j API while the old library code can log into the same location via the redirection.

Alas, this results in

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)

I've tried higher and lower verision numbers on some of these jars and also digging through API documentation and such... but I'm unable to find and solve the problem.

Help, please?

Although logback is considered the "strategic" logging framework, I have some leeway in which logging mechanism I ultimately use. I'd hope to use either logback or log4j, though, and I definitely want to merge the old project's logging into whatever the "new" logging framework ends up being, via a common configuration.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

苍景流年 2024-09-21 16:35:30

您将 1.5.6 版本的 jcl 桥与 1.6.0 版本的 slf4j-api 混合在一起;由于 1.6.0 中的一些更改,这不起作用。两者使用相同的版本,即 1.6.1(最新)。我一直使用 jcl-over-slf4j 桥,它工作得很好。

You are mixing the 1.5.6 version of the jcl bridge with the 1.6.0 version of the slf4j-api; this won't work because of a few changes in 1.6.0. Use the same versions for both, i.e. 1.6.1 (the latest). I use the jcl-over-slf4j bridge all the time and it works fine.

破晓 2024-09-21 16:35:30

SLF4J 1.5.11 和 1.6.0 版本不兼容(请参阅 兼容性报告),因为 org.slf4j.spi.LocationAwareLogger.log 方法的参数列表已更改(添加了 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 )

请参阅此页面上其他 SLF4J 版本的兼容性报告< /a>.

您可以通过 japi-compliance-checker 工具生成此类报告。

输入图片此处描述

SLF4J 1.5.11 and 1.6.0 versions are not compatible (see compatibility report) because the argument list of org.slf4j.spi.LocationAwareLogger.log method has been changed (added 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 )

See compatibility reports for other SLF4J versions on this page.

You can generate such reports by the japi-compliance-checker tool.

enter image description here

心意如水 2024-09-21 16:35:30

只是为了帮助那些与我有类似情况的人...

这可能是由于依赖库意外捆绑了旧版本的 slf4j 造成的。就我而言,它是 tika-0.8。请参阅https://issues.apache.org/jira/browse/TIKA-556

解决方法是排除该组件,然后手动依赖于正确的或修补的版本。

例如。

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

Just to help those in a similar situation to myself...

This can be caused when a dependent library has accidentally bundled an old version of slf4j. In my case, it was tika-0.8. See https://issues.apache.org/jira/browse/TIKA-556

The workaround is exclude the component and then manually depends on the correct, or patched version.

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>
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文