Config refresh fails for a @ConfigurationProperties bean that is proxied twice
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 56/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- java, spring, spring-boot
- 领域
- backend
调研方向
Start with ConfigurationPropertiesRebinder.rebind() and trace how it gets the target class and replaces a nested AOP proxy; compare that path with the reproducer at https://github.com/tommyk-gears/spring-cloud-double-proxy-refresh. Run ./gradlew test in the reproducer against the affected versions, then verify refresh succeeds for a double-proxied @ConfigurationProperties bean and that other beans are rebound after a failure.
由索引模型根据 Issue 内容生成。
描述
Versions: Spring Boot 4.1.2, Spring Cloud 2025.1.4 (spring-cloud-context 5.0.4). Also 5.0.2 and the build of #1779. Works with 5.0.1.
Reproducer: https://github.com/tommyk-gears/spring-cloud-double-proxy-refresh. ./gradlew test fails; the README lists how to run it against other versions.
What happens
A config refresh (POST /actuator/refresh, or ContextRefresher.refresh()) throws when a @ConfigurationProperties bean is an AOP proxy around another AOP proxy:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name
'com.example.repro.ReproApplication$DemoProperties$$SpringCGLIB$$0': Cannot invoke
"org.springframework.cglib.proxy.Dispatcher.loadObject()"
Caused by: java.lang.NullPointerException: Cannot invoke "org.springframework.cglib.proxy.Dispatcher.loadObject()"
at com.example.repro.ReproApplication$DemoProperties$$SpringCGLIB$$0.isFrozen(<generated>)
at org.springframework.aop.framework.AbstractAdvisingBeanPostProcessor.postProcessAfterInitialization(...)
...
at org.springframework.cloud.context.properties.ConfigurationPropertiesRebinder.rebind(...)
POST /actuator/refresh returns 500, the refreshScope health indicator is DOWN from then on, and since rebind() stops at the first failure, @ConfigurationProperties beans that had not been rebound yet keep their old values.
A double proxy comes about without anything unusual: in the reproducer, the properties class is @Validated, so the method validation post-processor proxies it, and an application aspect matching @Validated classes makes the AspectJ auto-proxy creator wrap that proxy again. We ran into it in a service whose aspect converts ConstraintViolationExceptions for @Validated classes, which broke refresh for four properties beans, three of them from a shared library.
Listing the class in spring.cloud.refresh.never-refreshable does not help either, since the check compares the same class (the inner proxy's) with the configured names. Only the bean name works.
What we found
Since 5.0.2 (ba34b47e), rebind() creates a fresh instance of an AOP-proxied bean with createBean(targetClass) and swaps it into the proxy. The target object is unwrapped recursively (ProxyUtils.getTargetObject), but targetClass comes from AopUtils.getTargetClass(bean), which unwraps one level. For a double proxy that is the class of the inner proxy, so createBean instantiates a CGLIB proxy class without its callbacks, and the first call on it fails. 5.0.1 rebound the unwrapped bean in place, which worked through the nested proxy.
This is separate from #1778; the build of #1779 fails the same way.
Possible directions, just as food for thought
- Use
AopProxyUtils.ultimateTargetClass(bean)for the target class and thenever-refreshablecheck. - Swap the fresh target into the innermost proxy rather than the outer one, so the advice of the inner proxy (here method validation) is kept.
- 主要语言
- Java
- 星标
- 750
- 派生
- 749
- 平均合并
- 19 小时 58 分钟
- 30 天内合并 PR
- 23
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
spring-cloud/spring-cloud-commons 的其他 Issue
-
waiting-for-triage
难度 2/5 1-3 小时 新手友好度 72/100
spring-cloud/spring-cloud-commons#1708 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 1/5 1 小时以内 新手友好度 65/100
spring-cloud/spring-cloud-commons#1543 ·
维护者通常 1 天内回复
-
`resetBeanToDefaults` transiently nulls nested `@ConfigurationProperties` objects, NPEing concurrent request threads可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭waiting-for-triage
难度 5/5 一周以上 新手友好度 48/100
spring-cloud/spring-cloud-commons#1727 · 4 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
enhancement for team discussion
难度 5/5 一周以上 新手友好度 42/100
spring-cloud/spring-cloud-commons#1676 ·
维护者通常 1 天内回复
-
waiting-for-triage
难度 5/5 一周以上 新手友好度 38/100
spring-cloud/spring-cloud-commons#1675 · 1 条评论 ·
维护者通常 1 天内回复
查看 spring-cloud/spring-cloud-commons 的全部 Issue
相似的 Issue
-
breaking change bug needs human review not ready priority medium size S
难度 2/5 1-3 小时 新手友好度 76/100
martin-francois/symphony-trello#1193 · 1 条评论 ·
维护者通常 1 天内回复
-
Mend: dependency security vulnerability
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 65/100
维护者通常 1 天内回复
-
status: waiting-for-triage
难度 2/5 1-3 小时 新手友好度 78/100
spring-projects/spring-framework#37614 ·
维护者通常 1 天内回复