[EarthChen]

Summary

Two samples import spring-boot-dependencies:1.5.22, which manages Spring Framework at 4.3.25.RELEASE. CI passes -Dspring.version=5.3.24. Maven 3.10.0 restricts interpolation of remotely resolved models (release notes — Security Hardening), so the -D no longer reaches the BOM and Spring 4.3 comes back. The ubuntu-22.04 runner image upgraded Maven (20260828.587 → 20261002.596). Both samples now pin Spring locally.

 3-extensions/configcenter/dubbo-samples-configcenter-externalconfiguration/pom.xml
 3-extensions/protocol/dubbo-samples-rest/pom.xml

 <properties>
   <spring-boot.version>1.5.22.RELEASE</spring-boot.version>
+  <spring.version>5.3.24</spring.version>

 <dependencyManagement>
   <dependencies>
+    <import>spring-framework-bom:${spring.version}</import>   <!-- first: wins -->
     <import>spring-boot-dependencies:1.5.22</import>          <!-- manages spring 4.3.25 -->

Spring 4.3 breaks each sample differently:

flowchart LR
    A["-Dspring.version=5.3.24<br/>ignored on Maven 3.10"] --> B["spring-core 4.3.25"]
    B --> C["externalconfiguration:<br/>cglib on JDK 16+<br/>InaccessibleObjectException"]
    B --> D["rest:<br/>commons-logging 1.3.4 + log4j-api 2.7<br/>NoSuchMethodError"]

Loading

Evidence

• Before (externalconfiguration): times out (600s) on the Dubbo CI Java 21 matrix (apache/dubbo run 38043764351):

  java.lang.InaccessibleObjectException: Unable to make ... java.lang.ClassLoader.defineClass(...)
    accessible: module java.base does not "opens java.lang" to unnamed module
    at org.springframework.cglib.core.ReflectUtils$1.run(ReflectUtils.java:61) ~[spring-core-4.3.25.RELEASE.jar:...]
  

  After: mvn dependency:tree -Dspring.version=5.3.24 (Maven 3.10.0) resolves spring-core:5.3.24 and spring-jcl:5.3.24. This is the combination that ran green before the image update (run 35845285402, passed in 28s).

• Before (rest): Job5 fails on all four JDKs (8, 11, 17, 21) in run 38389549733. RestProvider dies at startup, the container stays unhealthy, and the scenario times out:

  java.lang.NoSuchMethodError: 'boolean org.apache.logging.log4j.spi.LoggerContextFactory.isClassLoaderDependent()'
    at org.apache.commons.logging.impl.Log4jApiLogFactory$LogAdapter.getContext(Log4jApiLogFactory.java:161)
    at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:161)
    at org.apache.dubbo.samples.rest.RestProvider.main(RestProvider.java:32)
  

  Local mvn dependency:tree -Dspring.version=5.3.24 -Ddubbo.version=3.2.20 on Maven 3.10.0 resolved spring-core:4.3.25.RELEASE plus commons-logging:1.3.4. commons-logging 1.3.4 ships Log4jApiLogFactory, which needs a newer log4j-api than the 2.7 on the classpath.

  After: same command on this branch resolves spring-core:5.3.24 and spring-jcl:5.3.24, with no commons-logging on the classpath.

• Also verified on both modules: without -D the default 5.3.24 applies, and -Dspring.version=6.1.5 (externalconfiguration) or -Dspring.version=4.3.25.RELEASE (rest) still override. Spring Boot stays at 1.5.22.RELEASE.

• CI on this PR: configcenter-externalconfiguration passes on Java 8, 11, 17 and 21. The rest result on the new commit is the end-to-end confirmation.

Merge Danger

Door: two-way

Two POM changes to two sample modules. No library or workflow code is touched, and either change reverts cleanly.

Blast Radius: two samples

Both modules' case-versions.conf already declare spring.version=4.*, 5.*, so the CI matrix contract is unchanged. A scan of every module with a spring.version entry found no other sample on Spring Boot 1.x without a Spring pin.

rest allows spring.version=4.* in its matrix. If CI ever runs a 4.x version, commons-logging 1.3.4 and log4j-api 2.7 break again. This PR does not address that; CI runs only 5.3.24 today.

🤖 Generated with Claude Code