Lazily retrieve delegate beans in AsyncConfigurer and CachingConfigurer [SPR-17021]

[spring-projects-issues]

Marcin Grzejszczak opened SPR-17021 and commented

Having such code

@Configuration
@EnableAsync
public class FrontendAsyncConfigurerSupport extends AsyncConfigurerSupport {

    @Autowired BeanFactory beanFactory;

    @Override
    public Executor getAsyncExecutor() {
        return beanFactory.getBean(ThreadPoolTaskExecutor.class);
    }

    @Override public AsyncUncaughtExceptionHandler getAsyncUncaughtExceptionHandler() {
        return null;
    }
    
    @Bean
    ThreadPoolTaskExecutor myTaskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(10);
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(500);
        executor.setThreadNamePrefix("AsyncExecutor-");
        executor.initialize();
        return executor;
    }
} 

The myTaskExecutor is not applicable to get wrapped via proxy. In Spring Cloud Sleuth we're doing our best so that all instrumentation gets done automatically, behind the scenes. In this case a user has to manually call Sleuth internals to wrap the ThreadPoolTaskExecutor in a tracing representation.

---

Affects: 5.0.7

Reference URL: spring-cloud/spring-cloud-sleuth#1022

Issue Links:

• Doc: AsyncConfigurer causes dependencies to be created early [SPR-16945] #21484 Doc: AsyncConfigurer causes dependencies to be created early

Referenced from: commits f6fdffd

[spring-projects-issues]

Juergen Hoeller commented

A related case has been reported in #21484... While there is not much we can do about that case of triggering hard references to other beans from an AsyncConfigurer class, we should be able to make your case here - Executor post-processing - possible through lazily accessing the executor as well as the exception handler. I'll see what we can do for 5.1 here.