Package org.springframework.batch.core.configuration.annotation

Annotation Interface EnableBatchProcessing

@Target(TYPE)
@Retention(RUNTIME)
@Documented
@Import(BatchConfigurationSelector.class)
public @interface EnableBatchProcessing

Enable Spring Batch features and provide a base configuration for setting up batch jobs in an @Configuration class, roughly equivalent to using the <batch:*> XML namespace.

 @Configuration
 @EnableBatchProcessing
 @Import(DataSourceConfiguration.class)
 public class AppConfig {

        @Autowired
        private JobBuilderFactory jobs;

        @Bean
        public Job job() {
                return jobs.get("myJob").start(step1()).next(step2()).build();
        }

        @Bean
    protected Step step1() {
       ...
    }

        @Bean
    protected Step step2() {
     ...
    }
 }
 

You should provide a DataSource as a bean in the context or else implement BatchConfigurer in the configuration class itself -- for example:

 @Configuration
 @EnableBatchProcessing
 public class AppConfig extends DefaultBatchConfigurer {

    @Bean
    public Job job() {
       ...
    }

    @Override
    protected JobRepository createJobRepository() {
       ...
    }

  ...

 }
 

If multiple DataSource instances are defined in the context, the primary autowire candidate is used. Otherwise, an exception is thrown. Note that only one of your configuration classes needs to have the @EnableBatchProcessing annotation. Once you have an @EnableBatchProcessing class in your configuration, you have an instance of StepScope and JobScope, so your beans inside steps can have @Scope("step") and @Scope("job") respectively. You can also use @Autowired to insert some useful beans into your context:

• a JobRepository (bean name "jobRepository" of type SimpleJobRepository)
• a JobLauncher (bean name "jobLauncher" of type TaskExecutorJobLauncher)
• a JobRegistry (bean name "jobRegistry" of type MapJobRegistry)
• a JobExplorer (bean name "jobExplorer" of type SimpleJobExplorer)
• a JobBuilderFactory (bean name "jobBuilders") as a convenience to prevent you from having to inject the job repository into every job, as in the earlier examples
• a StepBuilderFactory (bean name "stepBuilders") as a convenience to prevent you from having to inject the job repository and transaction manager into every step

The transaction manager provided by this annotation is of type JdbcTransactionManager and is configured with the DataSource provided within the context. To use a custom transaction manager, you should provide a custom BatchConfigurer -- for example:

 @Configuration
 @EnableBatchProcessing
 public class AppConfig extends DefaultBatchConfigurer {

    @Bean
    public Job job() {
       ...
    }

    @Override
    public PlatformTransactionManager getTransactionManager() {
       return new MyTransactionManager();
    }

  ...

 }
 

If the configuration is specified as modular=true, the context also contains an AutomaticJobRegistrar. The job registrar is useful for modularizing your configuration if there are multiple jobs. It works by creating separate child application contexts to contain job configurations and register those jobs. The jobs can then create steps and other dependent components without needing to worry about bean definition name clashes. Beans of type ApplicationContextFactory are automatically registered with the job registrar. Example:

 @Configuration
 @EnableBatchProcessing(modular=true)
 public class AppConfig {

    @Bean
    public ApplicationContextFactory someJobs() {
       return new GenericApplicationContextFactory(SomeJobConfiguration.class);
    }

    @Bean
    public ApplicationContextFactory moreJobs() {
       return new GenericApplicationContextFactory(MoreJobConfiguration.class);
    }

  ...

 }
 

Note that a modular parent context, in general, should not itself contain @Bean definitions for job, especially if a BatchConfigurer is provided, because cyclic configuration dependencies are likely to develop.

For reference, compare the first example shown earlier to the following Spring XML configuration:

 
 <batch>
     <job-repository />
     <job id="myJob">
       <step id="step1" .../>
       <step id="step2" .../>
     </job>
     <beans:bean id="transactionManager" .../>
     <beans:bean id="jobLauncher" class=
"org.springframework.batch.core.launch.support.TaskExecutorJobLauncher">
       <beans:property name="jobRepository" ref="jobRepository" />
     </beans:bean>
 </batch>
 
 

Author:

Dave Syer, Mahmoud Ben Hassine

Optional Element Summary

Optional Elements

Modifier and Type	Optional Element	Description
boolean	modular	Indicate whether the configuration is going to be modularized into multiple application contexts.

Element Details

modular

boolean modular

Indicate whether the configuration is going to be modularized into multiple application contexts. If true, you should not create any @Bean Job definitions in this context but, rather, supply them in separate (child) contexts through an ApplicationContextFactory.

Returns:

boolean indicating whether the configuration is going to be modularized into multiple application contexts. Defaults to false.

Default:

false