Make it possible to opt in to TaskExecutor auto-configuration when an Executor has already been defined

[blake-bauman]

There appears to be a bug in TaskExecutorConfiguration when creating an AsyncTaskExecutor bean, the condition is:

@ConditionalOnMissingBean(Executor.class)

instead of on AsyncTaskExecutor.

The result is, if an app creates a bean of type Executor (such as a ScheduledExecutorService), this results in Spring’s default AsyncTaskExecutor beans to not be created. The application will fail to start because of the missing beans.

This is for apps trying to use the bean generated for the configuration with the Task Execution and Scheduling feature. If an app creates a bean of type Executor, the above bean never gets created.

[blake-bauman]

I've attached a sample project which reproduced the issue. If you run it, you'll see it fails to start due to a missing AsyncTaskExecutor bean. If you comment out the ScheduledExecutorService bean, then it succeeds.

test-spring-task-executors.tar.gz

[quaff]

I think @Bean method level @ConditionalOnMissingBean should be used instead of class level @ConditionalOnMissingBean(Executor.class).

It should only back off for TaskExecutor not Executor.

My proposal: https://github.com/spring-projects/spring-boot/compare/main...quaff:patch-137?expand=1

[quaff]

Or @ConditionalOnMissingBean(value =Executor.class, ignored = ScheduledExecutorService.class) ?

It make sense since ScheduledExecutorService should be used for scheduling task only.

[snicoll]

It should only back off for TaskExecutor not Executor.

I disagree with that and this bit of the auto-configuration is a bit tricky, I reckon. This is due to the bridge we had before the executor abstraction was available in the JDK. The condition on Executor is on purpose as users may define such a bean and expects the auto-configuration to back-off.

[blake-bauman]

@quaff ScheduledExecutorService was just an example. Any bean of type Executor will cause an app to fail startup if they need the AsyncTaskExecutor.

users may define such a bean and expects the auto-configuration to back-off

@snicoll We've found the opposite. Users define a bean for other purposes but expect to still use the AsyncTaskExecutor for other tasks.

[nosan]

@blake-bauman

Users define a bean for other purposes but expect to still use the AsyncTaskExecutor for other tasks.

In this case, you can use defaultCandidate=false annotation attribute and inject your ScheduledExecutorService using the @Qualifier annotation.
Here's an example based on what you shared earlier, with a slight adjustment:

@Bean(defaultCandidate = false)
@Qualifier("myexecutor")
public ScheduledExecutorService executorService() {
    return Executors.newSingleThreadScheduledExecutor();
}

This way, you will have both the auto-configured Executor and your custom ScheduledExecutorService.

[snicoll]

@snicoll We've found the opposite. Users define a bean for other purposes but expect to still use the AsyncTaskExecutor for other tasks.

I am sure that does happen. Hopefully what follows explain in more details what I meant.

@jhoeller and I discussed this one at length as I was trying to get back the context of why we did this that way. The conditions currently aren't ideal but they aren't out of place either.

AsyncAnnotationBeanPostProcessor looks for a bean named taskExecutor and with type Executor. Many users have historically created such custom Executor and called it taskExecutor. If we changed the condition, then the auto-configuration would attempt to override the user's bean with the auto-configured one. We can't do that.

We could improve the condition to only backoff if no beans named taskExecutor or applicationTaskExecutor have been defined but that then means that if you created a bean with a different name and only want that then you'd have to exclude the auto-configuration somehow. That's not ideal either.

The auto-configuration creates builder that applies the logic of the auto-configuration so you could do something as follows:

@Bean
Executor myCustomExecutor() { ... }

@Bean
SimpleAsyncTaskExecutor taskExecutor(SimpleAsyncTaskExecutorBuilder builder) {
    return builder.build();
}

SimpleAsyncTaskExecutorBuilder and friends are created irrespective of the presence of an Executor bean for that very reason. I think if you have custom executors in the context, being explicit about things might be the best way out.

This is flagged for team meeting so we'll discuss this ASAP, and hopefully we can find another way that would improve the current situation.

[wilkinsona]

@snicoll and I discussed this today.

As things stand, the best way to retain the auto-configured AsyncTaskExecutor is to use @Bean(defaultCandidate = false) (as @nosan has described above):

@Bean(defaultCandidate = false)
@Qualifier("myexecutor")
ScheduledExecutorService executorService() {
    return Executors.newSingleThreadScheduledExecutor();
}

This requires Spring Framework 6.2 so is only possible in Boot 3.4 and later.

For Boot 3.3, you can use the builder to define your own AsyncTaskExecutor with minimal code as @snicoll has shown above. One thing to note is that the equivalent auto-configured bean would be named both taskExecutor and applicationTaskExecutor. This is significant as the names control its consumption elsewhere. Framework will use a bean named taskExecutor for @Async task processing. Boot will apply a bean named applicationTaskExecutor in a number of places including MVC, WebFlux, and JPA bootstrapping. You can retain this behavior by naming your AsyncTaskExecutor in the same manner:

@Bean(name = {"taskExector", "applicationTaskExecutor"})
SimpleAsyncTaskExecutor taskExecutor(SimpleAsyncTaskExecutorBuilder builder) {
    return builder.build();
}

We'd like to improve this. Unfortunately, it's complicated by existing Framework behavior.

Framework will look for a unique bean of a particular type. When there a multiple beans of that type, it will look for a bean of a particular type with a specific name (taskExecutor for async task execution or taskScheduler for task scheduling). If Boot were to continue auto-configuring a bean when another matching bean already existed, it would break some existing arrangements. If Boot's bean used one of the special names, it could change the bean that's used for task execution or scheduling or result in a failure due to multiple beans with the same name. Regardless of the name, it would make ambiguous any injection points that expected a single bean of that type.

A further complication here is that there is overlap between the types that can be used for task scheduling and async task execution. This overlap further hinders any attempt to infer intent from the beans that have bean defined.

To avoid problems described above, particularly when upgrading, we think any new behavior will have to be gated by a property. We're currently envisaging two boolean properties, one for task execution and one for scheduling. By setting one or both properties to true, you can then opt in to Boot auto-configuring its bean for task scheduling or task execution when it would have currently backed off.

Focusing on the task execution case as that's the subject of this issue, setting the property to true would result in Boot configuring its task executor bean, even if there's an existing Executor bean in the context. It would be named applicationTaskExecutor to ensure that it's picked up by MVC, JPA bootstrapping, etc and an AsyncConfigurer would be used to configure Framework to use it for async task execution. There are some wrinkles to consider, such as Framework only supporting a single AsyncConfigurer, but we believe that can be addressed by defining a @Primary AsyncConfigurer that delegates to the other one.

To allow this issue to keep its focus on task execution, I have opened #44806 for the task scheduling side of things.