apache / apache/rocketmq

[Bug] Remove dependency on `rocketmq-slf4j-api`

Open
#9,127 3 comments 3 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.