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 typeSimpleJobRepository
) - a
JobLauncher
(bean name "jobLauncher" of typeTaskExecutorJobLauncher
) - 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 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
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 ElementsModifier 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, 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
-