Consistently accept "taskExecutor" bean of type Executor (as stated in @EnableAsync's javadoc) [SPR-15566]

[spring-projects-issues]

Sebastian Kirsch opened SPR-15566 and commented

The javadoc of @EnableAsync states

By default, Spring will be searching for an associated thread pool definition: either a unique org.springframework.core.task.TaskExecutor bean in the context, or an java.util.concurrent.Executor bean named "taskExecutor" otherwise.

That is only partly true, since any java.util.concurrent.Executor bean, no matter how it is named, will not be considered and the fallback SimpleAsyncTaskExecutor will be used. I can provide a test case if that is debatable.

It would further be helpful to state that an AsyncConfigurer takes precedence over any registered TaskExecutor.

---

Affects: 4.3.8

Issue Links:

• Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x [SPR-14030] #18602 Regression: Early instantiation of a bean prevents proxying for @Async in 4.2.x but works in 4.1.x
• ScheduledAnnotationBeanPostProcessor should fall back to default TaskScheduler by name [SPR-13236] #17827 ScheduledAnnotationBeanPostProcessor should fall back to default TaskScheduler by name
• AsyncAnnotationBeanPostProcessor could find TaskExecutor by type/name [SPR-13248] #17839 AsyncAnnotationBeanPostProcessor could find TaskExecutor by type/name

Referenced from: commits 3cc94ae, 9cb9884

[spring-projects-issues]

Juergen Hoeller commented

Our default executor lookup implementation was somewhat inconsistent: It accepted a "taskExecutor" bean of type Executor as a fallback if TaskExecutor beans were found but not unique; however, it did not accept such a "taskExecutor" bean on its own. I've revised this for 4.3.9 now.