We have quite a big application with a big spring context. We're migrating from Spring 5 to Spring 6 (6.2.16) and came across some strange behaviour.
In our application, we have a BeanDefinitionRegistryPostProcessor that programmatically registers bean definitions.
We are also using spring-security, and an issue seems to come from OAuth2AuthorizedClientManagerRegistrar calling getBeanNamesForType.
Now the issue: the application's spring context gets created with no errors or failures, however some singleton beans have their dependencies unset (null) even though they are annotated with @Autowired/@Resource.
As a result we seemingly have a running application that will throw NPEs at runtime - whenever a code path reaches the unset dependencies.
I've created a simple project that shows the issue.
Are we doing something wrong? I think that even if we are, the framework should not allow for the beans to be created with null dependencies.
spring-context-bug.zip
We have quite a big application with a big spring context. We're migrating from Spring 5 to Spring 6 (6.2.16) and came across some strange behaviour.
In our application, we have a
BeanDefinitionRegistryPostProcessorthat programmatically registers bean definitions.We are also using spring-security, and an issue seems to come from
OAuth2AuthorizedClientManagerRegistrarcallinggetBeanNamesForType.Now the issue: the application's spring context gets created with no errors or failures, however some singleton beans have their dependencies unset (null) even though they are annotated with
@Autowired/@Resource.As a result we seemingly have a running application that will throw NPEs at runtime - whenever a code path reaches the unset dependencies.
I've created a simple project that shows the issue.
Are we doing something wrong? I think that even if we are, the framework should not allow for the beans to be created with null dependencies.
spring-context-bug.zip