@Transactional beans not getting proxied when being initialized during failed circular reference attempt

[laoseth]

Currently using spring 4.3.22.RELEASE

Working in a large project with a bunch of circular preferences. When creating the bean structure, if bean creation fails initially(seeing a beanCreationException due to a failed ProxyBean creation without a known target class), the entire dependency graph of failed bean creations is rolled back. In our case, this includes our proxied @ Transactional bean. When the bean graph creation continues down a different, eventually successful path, the @ Transactional bean is recreated. However, during the original rollback, InfrastructureAdvisorAutoProxyCreator (extending AbstractAutoProxyCreator) isn't informed, so it's copy of earlyProxyReferences isn't informed that the early bean creation from earlier is gone, so when org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(Object, String) is called, it does not call wrapIfNecessary, as earlyProxyReferences still contains the bean name, from when it fails the first time.

Note, that if the circular reference causes a failure only once, this doesn't seem to happen, but if there are 2 failures, it seems to start returning unproxied beans. It appears to be the case that we have to be trying to wire the @ transactional bean into a bean in a different context for this to happen. It should be noted spring ends up initializing, just with missing proxies, which is almost worse than just failing, as the app comes up in an unknown state

[jhoeller]

This is available in 5.1.5.BUILD-SNAPSHOT from https://repo.spring.io/snapshot now. Feel free to give it an early try before the official 5.1.5 release on Wednesday...

It's also available in 4.3.23.BUILD-SNAPSHOT in case you'd like that branch a try. However, please note that the official 4.3.23 release is only scheduled for late March.

[laoseth]

Thank you for this fixed. It appears to have fixed the creation of non-proxied beans. We had some other issues behind it that have kept us from verifying it 100%