Config refresh fails for a @ConfigurationProperties bean that is proxied twice
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 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分
- マージ済み PR(30日)
- 23
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- 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 日以内に返信
-
waiting-for-triage
難易度 5/5 1週間以上 初心者へのやさしさ 48/100
spring-cloud/spring-cloud-commons#1727 · コメント 4 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
enhancement for team discussion
難易度 5/5 1週間以上 初心者へのやさしさ 42/100
spring-cloud/spring-cloud-commons#1676 ·
メンテナーはふだん 1 日以内に返信
-
waiting-for-triage
難易度 5/5 1週間以上 初心者へのやさしさ 38/100
spring-cloud/spring-cloud-commons#1675 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
spring-cloud/spring-cloud-commons の issue をすべて見る
似ている issue
-
pending:code-area pending:issue-category to-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
area:core bug priority:p2
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
aomarai/minecraft-mcp#247 ·
メンテナーはふだん 1 日以内に返信
-
help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
antonyrag/ragleap-core#1062 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
projectnessie/nessie#13256 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
Vakore/ZappierGames#232 ·