Allow customization of Spring Batch TaskExecutor

[aahlenst]

This PR addresses some concerns I raised in #27899, taking the discussion therein into account. My primary objective is to make it easier for newcomers to use Spring Batch properly.

Currently, the support for Spring Batch is geared towards single-job containerized Spring Boot apps orchestrated by a job scheduler. I pointed that out in the docs because it's not obvious. I also added a note that using Spring Batch as part of a web app is a viable option but that it requires some configuration, namely configuring an asynchronous TaskExecutor. Doing that is awkward because it requires overriding either BasicBatchConfigurer or JpaBatchConfigurer. Picking the right one requires knowledge about the Spring Batch auto-configuration. To avoid that I introduced @BatchTaskExecutor (modeled after @BatchDataSource). Thanks to @BatchTaskExecutor, swapping the TaskExecutor used by Spring Batch is now a matter of defining an additional bean.

[snicoll]

@aahlenst the ask sounds sensible, but I am not keen to introduce a dedicated annotation for this. The issue is already flagged for team attention so let's see what the rest of the team thinks.

[wilkinsona]

I have no objections to adding @BatchTaskExecutor here. As already noted, it feels nicely aligned with @BatchDataSource. I think it also fits fairly well with @FlywayDataSource, @LiquibaseDatasource, etc.

[snicoll]

My original comment was lacking context. In #27899, it was identified that the default sync task executor is preferred, which rules out associating "the" TaskExecutor that is available in the context (we auto-configure one by default and it's definitely not suitable as Spring Batch's default).

@BatchDataSource was used as a qualifier when multiple datasources are available in the context, and to be able to elect the one that we want to use for batch processing. It has some semantic attached to it, i.e. "if you have multiple datasources in the context, we don't know which one to use so add this qualifier to tell us".

We don't do this for the task executor. We don't really want you to create one as a bean as it would feel strange that if only one is around, you still have to add the qualifier for this to work. Besides, if you create such a bean, then our regular auto-configuration for application task executions will back off.

If we want to improve the scenario of specifying a custom task executor, perhaps a customizer of some sort could be used?

[wilkinsona]

Besides, if you create such a bean, then our regular auto-configuration for application task executions will back off

I'd overlooked this aspect of it. While we have the same problem with, for example, @BatchDataSource causing the main auto-configured DataSource to back off, I still think it's worth looking at a different approach. If we ever tackle #22403 we could then reconsider something based on a TaskExecutor bean.

[aahlenst]

According to my plan, there would always be the auto-configured TaskExecutor (or its manually configured replacement) and, if enabled, the additional @BatchTaskExecutor. But as you correctly pointed out, the auto-configuration would back off if it encountered a @BatchTaskExecutor. Therefore, my proposal does not make any sense. I am also reluctant to introduce a customizer. A customizer would be another layer of indirection. To me, it does not feel worth the additional complexity and maintenance effort considering the little value it would provide. Thanks anyway!