konlue commented on PR #7917: URL: https://github.com/apache/shenyu/pull/7917#issuecomment-6317543675
Fixed, and thanks for the reproduction — you were right that the test only passed on the bean-name coincidence. I went with the first repair route: - `@EnableConfigurationProperties` is gone. The properties are now a conditional `@Bean` (`@ConditionalOnMissingBean` + `@ConfigurationProperties(prefix = "shenyu.k8s.deployment")`), so a user bean cleanly wins and the `apiClient` argument has exactly one candidate. - The pre-registration test now registers the bean under `preRegisteredProperties`. Against the previous configuration, it fails with the exact `NoUniqueBeanDefinitionException` you reported (two candidates: `preRegisteredProperties` and `shenyu.k8s.deployment-…`). - Added a second test asserting the client is built from the override. On the non-blocking points: - The assertions now use `getBeansOfType`. - `scaleByAction` returns the result, and `ScaleObserver` warns when it is `false`. - `Config.fromToken(..., true)` with the CA read into a `ByteArrayInputStream` (construction failures are caught so a bad CA still degrades to a logged no-op rather than failing startup). - The property entries use `=`. I also corrected the description below — you are right that the old code created the client on the plain binding path; the regression was the pre-registered-properties case. The ordering caveat for `@ConditionalOnMissingBean` on a scanned `@Configuration` is noted as a follow-up rather than refactoring to `@AutoConfiguration` here. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
