Repository: apache/rocketmq

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.

Duplicate issue #8111: [Bug] The lettuce log appears in rocketmq_client.log, although rocketmq does not use this package, but why lettuce logs will be output to rocketmq_client.log? lettuce package when redis topology features a dependency.
Created: 2024-05-08T06:30:26Z
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
Darwin frank 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T8101 arm64
RocketMQ version
4.6.0
JDK Version
JDK:java version "1.8.0_321"
Describe the Bug
The lettuce log appears in rocketmq_client.log, although rocketmq does not use this package, but why lettuce logs will be output to rocketmq_client.log? lettuce package when redis topology features a dependency.
This instance of rocketmq acts as both a provider and a consumer.
Steps to Reproduce

rocketmq acts as a provider as well as a consumer.
redis has topology refresh enabled and checks for 30 seconds.
logs are entered into rocketmq_client.log while redis is checking.

lettuce-core：5.1.7.RELEASE
spring-boot-starter-data-redis：2.4.1
spring-data-redis：2.1.9.RELEASE
What Did You Expect to See?
Hopefully the log about lettuce doesn't hit rocketmq_client.log
What Did You See Instead?
The lettuce log is output in rocketmq_client.log which is not correct.
Additional Context
There is the following log in rocketmq-client.log:
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] channelActive()
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:23,023 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0xe7773456, /10.8.0.27:57227 -> 172.17.48.140/172.17.48.140:6379, last known addr=172.17.48.140/172.17.48.140:6379] userEventTriggered(ctx, io.lettuce.core.ConnectionEvents$Activated@1358e27d)
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.cluster.PooledClusterConnectionProvider$DefaultClusterNodeConnectionFactory - Resolved SocketAddress 172.17.48.40:6379 using for Cluster node at 172.17.48.40:6379
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.cluster.PooledClusterConnectionProvider$DefaultClusterNodeConnectionFactory - Resolved SocketAddress 172.17.48.40:6379 using for Cluster node at 172.17.48.40:6379
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.cluster.PooledClusterConnectionProvider$DefaultClusterNodeConnectionFactory - Resolved SocketAddress 172.17.48.40:6379 using for Cluster node at 172.17.48.40:6379
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0x504f668d, /10.8.0.27:57228 -> 172.17.48.40/172.17.48.40:6379, last known addr=172.17.48.40/172.17.48.40:6379] channelActive()
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0x504f668d, /10.8.0.27:57228 -> 172.17.48.40/172.17.48.40:6379, last known addr=172.17.48.40/172.17.48.40:6379] channelActive()
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0x504f668d, /10.8.0.27:57228 -> 172.17.48.40/172.17.48.40:6379, last known addr=172.17.48.40/172.17.48.40:6379] channelActive()
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0x504f668d, /10.8.0.27:57228 -> 172.17.48.40/172.17.48.40:6379, last known addr=172.17.48.40/172.17.48.40:6379] channelActive()
2024-05-06 16:25:24,024 DEBUG io.lettuce.core.protocol.ConnectionWatchdog - [channel=0x504f668d, /10.8.0.27:57228 -> 172.17.48.40/172.17.48.40:6379, last known addr=172.17.48.40/172.17.48.40:6379] channelActive()

Closing comment (2024-05-17T07:48:17Z): Hello, is this issue related to #5347? The situation feels the same as this one, it's because logback is bound by default, so components that use log4j don't work correctly. Is this the reason for this? And how can I solve this problem?