Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
#1,780 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
56/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java, spring, spring-boot
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

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 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.
Lenguaje dominante
Java
Estrellas
750
Forks
749
Merge medio
19 h 58 min
PR fusionados (30 d)
23

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de spring-cloud/spring-cloud-commons

Todos los issues de spring-cloud/spring-cloud-commons

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.