[cloudbase-ai]

Refs #7679. This is the SLF4J alignment slice; #7688 explicitly leaves SLF4J outside its annotation-alignment change.

Spring Boot 3.3.1 dependency management resolves slf4j-api to 2.0.13, below the 2.0.17 requested by shenyu-common → oshi-core:6.10.0. The explicit requireUpperBoundDeps check reproduces that conflict.

Import the official SLF4J 2.0.17 BOM before Spring Boot's BOM, matching the existing Netty BOM precedence pattern. This aligns the API and bridges together instead of upgrading only slf4j-api. No direct dependency is added; Logback, Spring Boot, Reactor and Enforcer configuration are unchanged. Downstream projects inheriting the ShenYu parent inherit these managed SLF4J versions unless they override them.

Version rationale: 2.0.17 is the minimum version already requested by the affected dependency graph. The SLF4J compatibility FAQ documents client API compatibility and matching provider major/minor versions. The 2.0.17 release notes state that its MDC initialization changes are transparent to existing logging backends. This patch stays on the existing 2.0 API line.

Validation with Java 17 and the repository Maven wrapper:

• Before/after: ./mvnw -B -ntp -pl shenyu-common -am org.apache.maven.plugins:maven-enforcer-plugin:3.6.3:enforce -Denforcer.rules=requireUpperBoundDeps. Before: SLF4J 2.0.13 and checker-qual 3.19.0 upper-bound errors. After: only checker-qual remains. The full command still exits 1 for that separate conflict; this PR does not claim whole-reactor dependency convergence or close [Task] Reactor dependency convergence / upper-bound alignment #7679.
• ./mvnw -B -ntp -pl shenyu-common,shenyu-admin,shenyu-bootstrap -am dependency:tree '-Dincludes=org.slf4j:*,ch.qos.logback:*' -Dverbose passed across 161 projects. Resolved SLF4J API, JCL bridge and JUL bridge are 2.0.17; Logback classic/core remain 1.5.6. The dependency plugin reports that verbose output is unsupported, so this check concerns resolved versions.
• ./mvnw -B -ntp -pl shenyu-common -am verify -Dmaven.javadoc.skip=true -Djacoco.skip=true passed: 515 tests, 0 failures/errors, 5 existing skips; Checkstyle and RAT passed.
• ./mvnw -B -ntp -pl shenyu-admin -am test -Dtest=DataChangedEventDispatcherTest,InstanceCheckServiceTest,InstanceInfoUtilsTest,LogUtilsTest,LoggingQueueMetricsTest -Dsurefire.failIfNoSpecifiedTests=false -Djacoco.skip=true -Dmaven.javadoc.skip=true passed: 64 Admin tests and 17 common test executions, no failures/errors.
• A standalone Java smoke probe used the resolved Admin test classpath, initialized MDC before LoggerFactory, attached a Logback ListAppender, and emitted direct fluent API, Commons Logging, and JUL-bridge messages. It asserted all three messages and their MDC values: SLF4J=2.0.17 LOGBACK=1.5.6 EVENTS=3 MDC=preserved.
• The separately parented E2E common reactor's dependency tree still resolves its explicit slf4j-api:1.7.35 and Log4j 2.18.0. Docker E2E itself was not run.
• git diff --check passed. No new implementation logic or mirrored-version tests were added for this POM-only change.

This does not enable hard-fail convergence rules or fix the annotation/framework conflicts tracked separately in #7679.

[Aias00]

Approving. The diagnosis is correct and the fix is at the right layer.

Verified while reviewing:

• shenyu-common/pom.xml declares com.github.oshi:oshi-core:6.10.0 with no slf4j-api exclusion, and oshi-parent-6.10.0.pom sets <slf4j.version>2.0.17</slf4j.version> (line 94) which oshi-core then uses for its slf4j-api dependency. Spring Boot's spring-boot-dependencies 3.3.1 manages slf4j-api to 2.0.13, so requireUpperBoundDeps genuinely fails without this change.
• org.slf4j:slf4j-bom:2.0.17 resolves on Maven Central and manages the whole family (slf4j-api plus jcl-over-slf4j, jul-to-slf4j, log4j-over-slf4j, slf4j-ext, slf4j-jdk14, slf4j-log4j12, slf4j-nop, slf4j-reload4j, slf4j-simple, osgi-over-slf4j, slf4j-jdk-platform-logging), so bridges stay aligned with the API instead of drifting from it.
• The import sits between netty-bom and spring-boot-dependencies, matching the existing precedence pattern and comment style in this file, so the first-wins semantics of imported BOMs gives 2.0.17 over Boot's 2.0.13.
• Importing a BOM does not leak its <properties> into this project, so the local slf4j.version property cannot collide with Boot's identically named property.

Non-blocking observations:

1. The PR description says "the explicit requireUpperBoundDeps check reproduces that conflict". The enforcer configuration in the root POM (enforce-build-requirements) only binds requireMavenVersion and requireJavaVersion, so this rule is a manual invocation, not something CI enforces. Worth either rewording the description or following up with a separate PR that adds requireUpperBoundDeps permanently — otherwise the same drift can silently reappear for the next dependency bump.
2. A narrower alternative would be excluding slf4j-api from oshi-core in shenyu-common. I prefer the BOM as written, because it fixes the whole family in one place and does not leave a second project vulnerable to the same transitive bump, but the description could say explicitly why the exclusion path was rejected.
3. slf4j.version now appears in the shared "dependency version" block and reads as if it were the project's canonical SLF4J version, whereas the project still inherits every other SLF4J-adjacent version from Boot. The inline comment on the import explains the intent; consider naming the property slf4j-bom.version or repeating the "must precede Spring Boot's BOM" note next to the property itself so future editors do not "clean up" the ordering.