[Bug] rmq.tools.logback.xml references an appender that is not defined in it, so mqadmin silently drops the Common/Store/Remoting logs #11431

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

OS: any (the mqadmin tool)

RocketMQ version

branch: develop
Git commit id: a7edeec

JDK Version

Compiler: Temurin 1.8.0_504 (target 1.8, same as CI)

Describe the Bug

tools/src/main/resources/rmq.tools.logback.xml — the configuration the distribution installs as conf/rmq.tools.logback.xml and that mqadmin selects with -Drmq.logback.configurationFile (distribution/bin/mqadmin:45) — attaches three loggers to an appender it never defines:

<logger name="RocketmqCommon" additivity="false" level="INFO">
    <appender-ref ref="RocketmqBrokerAppender"/>     <!-- not defined in this file -->
</logger>
<logger name="RocketmqStore" additivity="false" level="INFO">
    <appender-ref ref="RocketmqBrokerAppender"/>
</logger>
<logger name="RocketmqRemoting" additivity="false" level="INFO">
    <appender-ref ref="RocketmqBrokerAppender"/>
</logger>

The appenders this file defines are DefaultAppender, RocketmqToolsAppender, RocketmqToolsAppender_inner and STDOUT; RocketmqBrokerAppender only exists in the broker and proxy configurations, and logback resolves appender-refs inside the configuration file that is being loaded, so the reference cannot be satisfied.

The consequence is user-visible and completely silent: those loggers also set additivity="false", so once their only appender-ref is dropped they are attached to no appender at all — everything logged through RocketmqCommon, RocketmqStore and RocketmqRemoting is discarded and nothing from the client/store/remoting layers reaches tools.log (or any other appender), which is exactly the diagnostic trail an operator needs when a tool misbehaves. I verified with the project's own loader (JoranConfiguratorExt, the class the runtime uses) and a status collector that this logback build reports no status message at all for the unresolved reference — no warning, no error, so the loss is not even visible in the tool's output.

The sibling configurations do this correctly, which is the pattern to keep: broker points those loggers at its own RocketmqBrokerAppender, namesrv at RocketmqNamesrvAppender (namesrv/src/main/resources/rmq.namesrv.logback.xml:94-100), proxy at its RocketmqBrokerAppender. This is the same class of mistake that was fixed in #11177 (an appender registered under a name that did not match its definition).

Steps to Reproduce

1. Run any admin command, e.g. mqadmin clusterList -n 127.0.0.1:9876 (the wrapper passes conf/rmq.tools.logback.xml).
2. Check ${user.home}/logs/rocketmqlogs/tools.log: nothing logged by RocketmqCommon/RocketmqStore/RocketmqRemoting ever appears there, and no message is printed about the dropped configuration either.

At the unit level the shipped file is loaded with the project's own JoranConfiguratorExt (common/.../logging/JoranConfiguratorExt.java, the loader that also rewrites the unshaded logback class names for the shaded runtime) into a fresh logger context: the three loggers end up with no appender, and the loader reports no error or warning for it.

What Did You Expect to See?

mqadmin starts without configuration errors, and its component loggers write to the tool's own log file — i.e. the three loggers reference RocketmqToolsAppender (the appender the file defines and that RocketmqTools already uses, writing to ${user.home}/logs/rocketmqlogs/tools.log), mirroring how each other component points those loggers at its own appender.

What Did You See Instead?

Three logback errors on every invocation and three loggers whose output is silently discarded.

Additional Context

Minimal fix: replace the three RocketmqBrokerAppender references with RocketmqToolsAppender. I checked the other shipped configurations for the same mistake: only this file references an appender it does not define (the controller file defines RocketmqControllerConsole twice, but with identical content, which logback merges harmlessly).

I will open a PR with the three-line change plus a regression test that loads the shipped rmq.tools.logback.xml through JoranConfiguratorExt and asserts the three loggers are attached to an appender (red before: RocketmqCommon must be attached to an appender).