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() { ... } }The user should 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 multiple
DataSource
s are defined in the context, the primary autowire candidate
will be used, otherwise an exception will be 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 will have an
instance of StepScope
and JobScope
so your beans inside steps
can have @Scope("step")
and @Scope("job")
respectively. You will also be
able to @Autowired
some useful stuff into your context:
- a
JobRepository
(bean name "jobRepository" of typeSimpleJobRepository
) - a
JobLauncher
(bean name "jobLauncher" of typeSimpleJobLauncher
) - a
JobRegistry
(bean name "jobRegistry" of typeMapJobRegistry
) - a
JobExplorer
(bean name "jobExplorer" of typeSimpleJobExplorer
) - a
JobBuilderFactory
(bean name "jobBuilders") as a convenience to prevent you from having to inject the job repository into every job, as in the examples above - a
StepBuilderFactory
(bean name "stepBuilders") as a convenience to prevent you from having to inject the job repository and transaction manager into every step
DataSourceTransactionManager
configured with the DataSource
provided within the context.
In order to use a custom transaction manager, a custom BatchConfigurer
should be provided. 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
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>
- Author:
- Dave Syer, Mahmoud Ben Hassine
-
Optional Element Summary
Modifier and TypeOptional ElementDescriptionboolean
Indicate whether the configuration is going to be modularized into multiple application contexts.
-
Element Details
-
modular
boolean modularIndicate whether the configuration is going to be modularized into multiple application contexts. If true then you should not create any @Bean Job definitions in this context, but rather supply them in separate (child) contexts through anApplicationContextFactory
.- Returns:
- boolean indicating whether the configuration is going to be modularized into multiple application contexts. Defaults to false.
- Default:
- false
-