Repository: apache/rocketmq

Issue #9127: [Bug] Remove dependency on `rocketmq-slf4j-api`
Created: 2025-01-13T11:54:31Z
Before Creating the Bug Report


 I found a bug, not just asking a question, which should be created in GitHub Discussions.


 I have searched the GitHub Issues and GitHub Discussions  of this repository and believe that this is not a duplicate.


 I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.


Runtime platform environment
All
RocketMQ version
branch: develop
JDK Version
No response
Describe the Bug
Many RocketMQ artifacts depend on repackaged versions of SLF4J and Logback:

io.github.aliyunmq:rocketmq-slf4j-api
io.github.aliyunmq:rocketmq-logback-classic

This is IMHO a very bad idea, since:

It introduces yet another logging API that users need to forward to their logging implementation.
Naïve implementations of bridges between logging APIs have a tendency to lose location information (class, method and line number). io.github.aliyunmq:rocketmq-slf4j-api-bridge is not an exception and loses location information.
Using those dependencies introduces an additional entity to the RocketMQ supply chain: the aliyun.mq project. I am aware of the fact the aliyun.mq is mostly composed by members of the RocketMQ PMC, but it is still an independent project and is not covered by the ASF rules and Apache Security Team. This will cause a problem with CRA and similar regulations.
The rocketmq-logback-classic artifact is basically subject to the same vulnerabilities as logback-classic, but I don't see any CVE being issued against that artifact (Logback published 7 CVEs in 2023 and 2024).

Steps to Reproduce
You can see the problem by searching the pom.xml files for the artifacts mentioned above.
What Did You Expect to See?
I would expect:

All the RocketMQ artifacts to depend on org.slf4j:slf4j-api or another established logging API. (Note that the openrewrite/rewrite-logging-frameworks project contains rules to rewrite SLF4J to any other logging API, so the choice of logging API is not really binding).
Additionally the rocketmq-distribution artifact should have a runtime dependency on ch.qos.logback:logback-classic.
No other RocketMQ artifact should have a runtime dependency on Logback (see #5347). If Logback is used by the tests, it should be in the test scope.

What Did You See Instead?
All RocketMQ artifacts depend on the custom io.github.aliyunmq:rocketmq-slf4j-api logging API. Some of them depend on io.github.aliyunmq:rocketmq-logback-classic or io.github.aliyunmq:rocketmq-slf4j-api-bridge.
Additional Context
No response

Duplicate issue #5347: rocketmq-tools should not depend on logback-classic
Created: 2022-10-18T16:04:16Z
rocketmq-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.

Closing comment (2025-01-30T07:27:42Z): Due to changes in new RocketMQ versions, this issue is also related to #9127.
They can be fixed with a single PR.