问题描述
因此,我一直在移植一些服务,以便在log4j上使用Logback,并且我一直在使用log4j-over-slf4j jar欺骗log4j来保留我们的旧版依赖项.唯一的问题是log4j-over-slf4j没有实现log4j的许多类,因此我看到一些不错的类未从依赖的jar中找到异常.人们如何解决这个问题?仅将nlog4j放在类路径中而不是在log4j-over-slf4j jar中是否足够?我还没有测试过最后一个想法,但是我计划明天再做.
So I've been porting some of our services to use Logback over log4j and I've been using the log4j-over-slf4j jar to spoof log4j for our legacy dependencies. The only issue is log4j-over-slf4j doesn't implement many of the classes of log4j so I'm seeing a decent few class not found exceptions from dependent jars. How have people got around this? Is it enough to just put the nlog4j in your classpath instead of the log4j-over-slf4j jar? I haven't tested this last idea yet but I'm planning on it tomorrow.
参考:
- http://www.slf4j.org/legacy.html
- http://www.slf4j.org/nlog4j/
推荐答案
好吧,我想您正在面对桥接旧版API 中明确提到的问题"您发布的链接:
Well, I guess you're facing "problems" explicitly mentioned in the Bridging legacy APIs link you posted:
如果从属JAR受您控制,则您应该真正尝试使用 SLF4J迁移器工具.
If the dependent JARs are under your control, you should really try to migrate the code using the SLF4J Migrator tool.
这可能会解决ClassNotFoundException
,但我想知道整个日志记录将如何工作.鉴于 NLog4J 不再得到积极开发,我想知道这是否是一个长期的好选择解决方案.
This might solve the ClassNotFoundException
but I wonder how the whole logging is going to work. And given that NLog4J is no longer actively developed, I wonder if this is a good long term solution.
这篇关于用LogBack替换Log4j的问题,log4j-over-slf4j.jar的缺点的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!