Config refresh fails for a @ConfigurationProperties bean that is proxied twice #1780

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 (ba34b47), 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 the never-refreshable check.
• 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.