Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
rocketmq-tools should not depend on logback-classic
See original GitHub issuerocketmq-tools depends on logback-classic, which includes a StaticLoggerBinder class which binds slf4j to logback.
This binding shouldn’t be made by a library since only one binding can exist in the entire application, so any application that uses multiple libraries may have inconsistent bindings. The binding should be chosen only by the final application (i.e., the person implementing main()).
This, for example, causes warnings in openmessaging/benchmark which have chosen log4j binding, but the logback binding included from rocketmq causes a conflict.
It rocketmq-tools depended on logback-core instead, it would not include the slf4j binding which is one way to solve this problem.
Issue Analytics
- State:
- Created a year ago
- Comments:5 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
@travisdowns I think you are right. As a library,
rocketmq-toolsshould not introduce the facade and the implementation at the same time.I will start a RIP about replacing current logging module by a shaded logback recently, which may also solve this problem, you could view the related code from https://github.com/aliyun-mq/rocketmq-logging.
@aaron-ai any idea?