You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Given the existing configure(T) method, I can't see much benefit to a Supplier-based approach. To avoid using reflection by default, we could change build() to the following:
public ThreadPoolTaskExecutor build() {
return configure(new ThreadPoolTaskExecutor());
}
This would remove the use of reflection in the code path driven by TaskExecutionAutoConfiguration. Anyone using TaskExecutorBuilder themselves can make a similar change and call configure(new T()) rather than build(Class<T>).
Makes sense I think. Just one possible snag: TheadPoolTaskExecutor is BeanNameAware and InitializingBean and DisposableBean. We might need to take care of those callbacks as well (although I can't see that they are being called right now)?
If you want those callbacks to be invoked, the expectation is that the instance that's built or configured by TaskExecutorBuilder is defined as a @Bean as we do in TaskExecutionAutoConfiguration.
wilkinsona
changed the title
TaskExecutorBuilder uses reflection to create a TaskExecutor by default
Avoid unnecessary reflection in TaskExecutorBuilder
Sep 1, 2020
It could easily keep the existing methods but switch to using a
Supplier
and method references.The text was updated successfully, but these errors were encountered: