Rethink DefaultBatchConfiguration and/or change documentation #41958
Labels
for: external-project
For an external project and not something we can fix
status: invalid
An issue that we don't feel is valid
Uh oh!
There was an error while loading. Please reload this page.
Hi, I think
DefaultBatchConfiguration
has some issues that need to be addressed:The documentation suggests, that it should be extended
Quote:
DefaultBatchConfiguration
. But following Composition over Inheritance, you would rather want to import it.DefaultBatchConfiguration
should probably be to override e. g.getTaskExecutor()
, allowing you to customize the Batch infrastructure. But then again, following Composition over Inheritance, it might be better to let the user provide a factory bean combined with a customizer.JobRepositoryFactoryBean
, but these are hard coded and can neither be changed nor customized by the user.DefaultBatchConfiguration
. This mixes two things that, IMO, should not be mixed: Batch infrastructure configuration and job configurations. What if you want to have multiple classes that define jobs, would you then extendDefaultBatchConfiguration
multiple times? If you do that, from which class will the beans be taken? Imagine overridinggetTaskExecutor()
in multiple subclasses. Only one will win. So as a user, you most likely want to subclassDefaultBatchConfiguration
at most once and put jobs into separate configs. Therefore, the current doc might send users on the wrong path.Beans can't be replaced
Even if customizable bean factories were provided, it would still not work well with Spring Boot AutoConfiguration where users expect beans to be replaceable. See #40040
Therefore, if you want to use a different
JobRepository
bean, you can't use this class and have to specify all the beans on your own.I'm interested in reading your thoughts. When I find the time, I would also like to provide suggestions. Unfortunately, I can't right now.
The text was updated successfully, but these errors were encountered: