Java Reference
In-Depth Information
9-2. Setting Up Spring Batch's Infrastructure
Spring Batch provides a lot of flexibility and guarantees to your application, but it cannot work in a
vacuum. To do its work, the JobRepository requires a database. Additionally, there are several
collaborators required for Spring Batch to do its work. This configuration is mostly boilerplate.
In this recipe, you'll set up the Spring Batch database and also create a Spring XML application context
that can be imported by subsequent solutions. This configuration is repetitive and largely uninteresting.
It will also tell Spring Batch what database to use for the metadata it stores.
How It Works
The JobRepository is the first thing that you'll have to deal with when setting up a Spring Batch process.
You usually don't deal with it in code, but in Spring configuration it is key to getting everything else
working. There's only one really useful implementation of the JobRepository interface, which stores
information about the state of the batch processes in a database. Creation is done through a
JobRepositoryFactoryBean . Another standard factory, MapJobRepositoryFactoryBean is useful mainly for
testing because its state is not durable. Both factories create an instance of SimpleJobRepository .
Because this JobRepository instance works on your database, you need to set up the schema for
Spring Batch to work with. The simplest way for me to get that schema was to simply download the
org.springframework.batch-2.0.0.RELEASE-with-dependencies.tar.gz and look in the sources folder at
sources/org.springframework.batch.core/src/main/resources . You'll find a slew of . sql files, each
containing the data definition language (DDL, the subset of SQL used for defining and examining the
structure of a database) for the required schema for the database of your choice. Make sure you
configure it and tell Spring Batch about it as in the following configuration:
<?xml version="1.0" encoding="UTF-8"?>
Search WWH ::

Custom Search