Getting Started With Spring Batch 2.0

Understanding The Football Sample Application 

Let's start from FootballJobFunctionalTests and work backwards.

Normally we wouldn't launch batch jobs from JUnit tests, but that's what we're doing here so let's look at that. The sample app uses the Spring TestContext framework, and without going into the gory details (they're not directly relevant to Spring Batch), it turns out that the TestContext framework provides a default application context file for FootballJobFunctionalTests; namely

org/springframework/batch/sample/FootballJobFunctionalTests-context.xml

inside the src/test/resources folder. Listing 1 shows what it contains.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">

    <import resource="classpath:/simple-job-launcher-context.xml" />
    <import resource="classpath:/jobs/footballJob.xml" />
</beans>

In listing 1 we can see that the app context provides a couple of things: first, it provides via the simple-job-launcher-context.xml import a JobLauncher bean so we can run jobs; second, it provides via the jobs/footballJob.xml import an actual job to run. Both of these live in the src/main/resources folder. Once you have a JobLauncher, a Job and a JobParameters (we're using an empty JobParameters bean for this sample app), all we have to do is this:

jobLauncher.run(job, jobParameters);

That's exactly what the FootballJobFunctionalTests class does, though you have to navigate up its inheritance hierarchy to AbstractBatchLauncherTests.testLaunchJob() to see it.

Anyway, let's look first at the JobLauncher.

Defining A JobLauncher

As noted above, the sample app defines the JobLauncher bean in simple-job-launcher-context.xml. We can see some of the bean dependencies in figure 3, courtesy of Spring IDE:

Listing 2 shows the corresponding application context file.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/aop
        http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
        http://www.springframework.org/schema/tx
        http://www.springframework.org/schema/tx/spring-tx-2.5.xsd">

    ... some imports ...

    <bean id="jobLauncher"
        class="org.springframework.batch.core.launch.support.
            SimpleJobLauncher"
        p:jobRepository-ref="jobRepository" />

    <bean id="jobRepository"
        class="org.springframework.batch.core.repository.support.
            JobRepositoryFactoryBean"
        p:dataSource-ref="dataSource"
        p:transactionManager-ref="transactionManager" />

    ... other bean definitions ...

</beans>

I've obviously suppressed some of the beans from the application context. The two beans we need to know about here are the JobLauncher itself and its JobRepositoryFactoryBean dependency, which is a factory for SimpleJobRepository instances. I already mentioned that the JobLauncher allows us to run jobs. The point of the JobRepository is to store and retrieve job metadata of the sort stored in the batch_xxx tables we saw earlier. Again we're not going to cover that here, but the basic idea is that the JobRepository contains information on which jobs we ran when, which steps succeeded and failed, and that sort of thing. That kind of metadata allows Spring Batch to support, for example, job retries.

We'll now consider the job definition itself.