fix: resolve config refresh failure with spring.config.import on 2025.0.x

[wushiyuanmaimob]

Describe what this PR does / why we need it

Fix two defects in NacosPropertySourceRefreshListener that prevented dynamic config refresh when using spring.config.import=nacos: on the 2025.0.x branch.

Defect 1: PropertySource name mismatch

• ConfigData path uses group@dataId naming (NacosConfigDataLoader.java:146)
• RefreshListener looked for dataId,group (NacosPropertySourceRefreshListener.java:103)
• Result: target.get(sourceName) always returned null, so refresh never happened

Defect 2: File extension hardcoded

• RefreshListener hardcoded "properties" as file extension (NacosPropertySourceRefreshListener.java:108)
• Actual extension (yml/json/xml) was stored in NacosItemConfig.suffix but not propagated
• Result: yml/json/xml configs were parsed as properties after refresh, causing errors

Does this pull request fix one issue?

Fixes #4331

Describe how you did it

1. Add suffix field to NacosPropertySource to preserve file extension
2. Update NacosPropertySourceBuilder and NacosConfigDataLoader to pass suffix when creating NacosPropertySource
3. Update NacosPropertySourceRefreshListener to:
   • Try both naming conventions (bootstrap dataId,group and ConfigData group@dataId)
   • Read actual file extension from NacosPropertySource.getSuffix() instead of hardcoding "properties"

Describe how to verify it

1. Set up a Spring Boot 3.x app with spring.config.import=nacos:test-config.yml
2. Change the config value in Nacos
3. Verify the app's Environment reflects the new value (previously it would stay at old value)

Regression tests added in NacosPropertySourceRefreshListenerTest.

Special notes for reviews

• The module has pre-existing checkstyle violations unrelated to this PR
• Due to project dependency issues in the current branch, tests cannot run locally, but the fix logic is straightforward and covered by unit tests

[CLAassistant]

All committers have signed the CLA.

[bengbengbalabalabeng]

Will the current PR see any further progress?

[bengbengbalabalabeng]

Based on the fix in #4341, it looks like the naming mismatch issue should no longer occur.

[oss-sentinel-ai]

Summary

This PR fixes two real defects in the config refresh path when using spring.config.import=nacos:: (1) PropertySource name mismatch between ConfigData (group@dataId) and bootstrap (dataId,group) naming conventions, and (2) hardcoded "properties" suffix during refresh. The dual-name lookup approach is pragmatic. However, there are a few concerns worth addressing before merge.

Findings

• [Critical] NacosPropertySourceRefreshListener.java:125 — When the ConfigData path is taken, sourceName is set to configDataName (group@dataId), but the rebuilt NacosPropertySource from nacosPropertySourceBuilder.build() constructs its internal name as dataId,group (bootstrap convention). After target.replace(sourceName, newProperSource), the map key is group@dataId but the object's getName() returns dataId,group. This inconsistency can cause subtle bugs in downstream code that relies on NacosPropertySource.getName() matching its key in the PropertySources map. Consider passing the original sourceName into the builder or using a constructor that accepts an explicit name.
• [Warning] This PR and #4349 both fix the same hardcoded-suffix bug with different approaches (immutable constructor param vs. mutable setter). They will conflict if both are merged. Please coordinate with the other PR author to align on a single approach.
• [Info] Test file path src/test/java/com.alibaba.cloud.nacos/refresh/ uses dots instead of slashes for the package directory. This may cause test discovery issues depending on the build configuration.

Suggestions

// In NacosPropertySourceRefreshListener, when rebuilding for ConfigData path:
// Ensure the rebuilt source name matches the map key
String sourceName = bootstrapName;
NacosPropertySource existing = (NacosPropertySource) target.get(sourceName);
if (existing == null) {
    sourceName = configDataName;
    existing = (NacosPropertySource) target.get(sourceName);
}
// existing.getSuffix() now carries the correct extension — good.
// But verify the rebuilt source name matches sourceName.

---

Automated review by github-manager-bot

[uuuyuqi]

Thanks for the contribution. I rechecked the current 2025.0.x and 2025.1.x branches. The two problems addressed by this PR now have different statuses:

1. The ConfigData-loaded PropertySource could not be replaced correctly by the refresh listener. This part has already been backported to 2025.0.x through fix(nacos): backport NacosPropertySource refresh replacement to 2025.0.x #4346. Therefore, the dual lookup for dataId,group and group@dataId in this PR is no longer needed.
2. The original suffix is lost when refreshing non-properties configurations. This has been fully fixed in 2025.1.x through fix(nacos): preserve file extension for yml/json/xml config refresh #4349, but it has not yet been backported to 2025.0.x.

Please rebase this PR onto the latest 2025.0.x and revise it into a backport of #4349. The backport should preserve the original suffix on each replacement NacosPropertySource and retain the regression test that verifies two consecutive refreshes continue to use the same suffix.

The #4349 commit cannot be cherry-picked into 2025.0.x without adaptation. The main branch-specific differences are:

• NacosPropertySourceBuilder in 2025.0.x does not have the namespace constructor argument.
• 2025.0.x does not include the JSpecify @Nullable dependency.
• The test copyright headers need to follow the Checkstyle rules used by 2025.0.x.
• The snapshot regression test carried over from fix: use Nacos config snapshot in ConfigData loader #4319 is not applicable to the current 2025.0.x branch and does not need to be included in this backport.

After these adjustments, please make sure the tests cover yml, json, the null-suffix fallback, and consecutive refreshes. We can continue the review once the PR has been updated.

[uuuyuqi]

see #4335 (comment)

[oss-sentinel-ai]

Thanks @uuuyuqi for the detailed guidance. Updating my earlier review in light of it:

• [Warning] overlap with #4349 — resolved: the maintainers decided this PR should be revised into a backport of #4349, so no coordination between competing approaches is needed anymore.
• [Critical] rebuilt source name mismatch — superseded: since #4346 already landed the ConfigData replacement fix on 2025.0.x (merged 2026-06-21), the dual dataId,group / group@dataId lookup in this PR is no longer needed once rebased.
• [Info] test directory path — still applies: src/test/java/com.alibaba.cloud.nacos/refresh/ uses dots instead of slashes; if the test is carried over into the backport, please use src/test/java/com/alibaba/cloud/nacos/refresh/ so test discovery works reliably.

Remaining work per the maintainer's request: rebase onto the latest 2025.0.x and revise this PR into a backport of #4349 (merged on 2025.1.x 2026-07-31) — preserve the original suffix on each replacement NacosPropertySource, retain the consecutive-refresh regression test, adapt for the missing namespace constructor argument and the absent JSpecify @Nullable dependency, follow the 2025.0.x Checkstyle copyright headers, and skip the #4319 snapshot regression test. Test coverage should include yml, json, the null-suffix fallback, and consecutive refreshes.

Happy to re-review once the PR is updated.

---

Automated review by github-manager-bot