[Bug] Remove dependency on `rocketmq-slf4j-api`
- Dominant language
- Java
- Stars
- 22.6k
- Forks
- 12k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 26
Description
### Before Creating the Bug Report
- [X] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions).
- [X] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate.
- [X] 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`](https://github.com/aliyunmq/rocketmq-slf4j-api-bridge)
- [`io.github.aliyunmq:rocketmq-logback-classic`](https://github.com/aliyunmq/rocketmq-logging)
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`](https://github.com/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](https://github.com/aliyunmq). 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](https://github.com/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`](https://github.com/apache/rocketmq/blob/develop/distribution/pom.xml) 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_
Contributor guide
Research direction
Search the repository's pom.xml files for rocketmq-slf4j-api, rocketmq-logback-classic, and rocketmq-slf4j-api-bridge, then inspect distribution/pom.xml and the dependency scopes around those artifacts. Done means RocketMQ artifacts use org.slf4j:slf4j-api, distribution has runtime logback-classic, and other Logback uses are test-scoped or absent.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100