@Target(value=TYPE) @Retention(value=RUNTIME) @Documented @Import(value=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() {
...
}
}
The user should to provide a DataSource as a bean in the context, or else implement BatchConfigurer in
the configuration class itself, e.g.
@Configuration
@EnableBatchProcessing
public class AppConfig extends DefaultBatchConfigurer {
@Bean
public Job job() {
...
}
@Override
protected JobRepository createJobRepository() {
...
}
...
}
If a user does not provide a DataSource within the context, a Map based
JobRepository will be used.
Note that only one of your configuration classes needs to have the @EnableBatchProcessing
annotation. Once you have an @EnableBatchProcessing class in your configuration you will have an
instance of StepScope so your beans inside steps can have @Scope("step"). You will also be
able to @Autowired some useful stuff into your context:
JobRepository (bean name "jobRepository")JobLauncher (bean name "jobLauncher")JobRegistry (bean name "jobRegistry")PlatformTransactionManager (bean name "transactionManager")JobBuilderFactory (bean name "jobBuilders") as a convenience to prevent you from having to inject the
job repository into every job, as in the examples aboveStepBuilderFactory (bean name "stepBuilders") as a convenience to prevent you from having to inject the
job repository and transaction manager into every stepmodular=true then the context will also contain an
AutomaticJobRegistrar. The job registrar is useful for modularizing your configuration if there are multiple
jobs. It works by creating separate child application contexts containing job configurations and registering 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 will be registered automatically 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 otherwise likely
to develop.
For reference, the first example above can be compared 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.SimpleJobLauncher">
<beans:property name="jobRepository" ref="jobRepository" />
</beans:bean>
</batch>
| Modifier and Type | Optional Element and Description |
|---|---|
boolean |
modular
Indicate whether the configuration is going to be modularized into multiple application contexts.
|
public abstract boolean modular
ApplicationContextFactory.