Spring Add AOT support for @Scope(proxyMode = ScopedProxyMode.TARGET_CLASS)

@snicoll @jhoeller It looks like this is not supported by AOT transformations:

@StepScope
@Bean
public ItemReaderListener reader() {
   ...
}

This is the equivalent of:

@Scope(value = "step", proxyMode = ScopedProxyMode.TARGET_CLASS)
@Bean
public ItemReaderListener reader() {
   ...
}

Since we don't have hints for CGLIB proxies, we are kind of blocked currently for this kind of Batch IO use case. See also the original Spring Native issue where this use case was supported.

Comment From: jhoeller

Scoped proxy detection seems to be broken at the moment due to an explicit "decorated definition" bypass in the BeanFactory implementation, always determining the type of the target bean instead. Removing that bypass makes the proxy discoverable through ScopedProxyFactoryBean.getObjectType() as part of our regular preDetermineBeanTypes algorithm, for CGLIB proxies as well as JDK proxies (auto-inferring the runtime hints for the latter).

The remaining question is why that (old) type determination bypass was needed in the first place. I'll revise this towards not being necessary for scoped proxies anymore at least, in time for the RC2 release.

Comment From: jhoeller

This should work now, with CGLIB proxy classes captured as well as runtime hints registered for both types of scoped proxies (no explicit hints necessary for either anymore).

Comment From: snicoll

Supporting a proxy at that level means that AOT exposes it and any container lifecycle callback is invoked on it. Looking at the AOT contribution for the scoped proxy, it's a bit odd as it's exposing the underlying type from the instance supplier. I bet this was done to make sure that type resolution works but I am not entirely sure it is still relevant.

Comment From: snicoll

This should now be fixed with https://github.com/spring-projects/spring-framework/commit/affccba8f1beccdb5910e4a0e909701d33255db5