Skip to content

Add ability to customize the job parameters converter in the default batch configuration #4650

Closed
@micheljung

Description

@micheljung

Hi, I think DefaultBatchConfiguration has some issues that need to be addressed:

The documentation suggests that it should be extended

Quote:

A typical usage of this class is as follows:

  @Configuration
  public class MyJobConfiguration extends DefaultBatchConfiguration {
 
      @Bean
      public Job job(JobRepository jobRepository) {
          return new JobBuilder("myJob", jobRepository)
                  // define job flow as needed
                  .build();
      }
 
  }
  1. This suggests to extend DefaultBatchConfiguration. But following Composition over Inheritance, you would rather want to import it.
  2. The only reason to extend 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 and/or a customizer.
  3. While it already uses factory beans like JobRepositoryFactoryBean, these are hard coded and can neither be changed nor customized by the user.
  4. The code above suggests defining job beans in your subclass of 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 extend DefaultBatchConfiguration multiple times? No, because if you do that, from which class will the beans be taken? Imagine overriding getTaskExecutor() in multiple subclasses: only one will win. So as a user, you most likely want to subclass DefaultBatchConfiguration at most once and put jobs into separate configs. Not everyone might realize this. Therefore, I think the doc shouldn't suggest mixing job config with infrastructure.

It makes auto configuration difficult for Spring Boot

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 spring-projects/spring-boot#40040
If the suggested solution works, this point might be invalid. Still, maybe it's something to be considered.

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions