Running a Job - Spring Batch - page 121

With your jar file named something that makes sense for your application ( helloWorld in this case),
you can run the job using the jar file itself from the <project_home>/target directory. Listing 6-3 shows
an example of how to run the HelloWorld job you've been running up to now using the Java command.
Listing 6-3. Basic Call to CommandLineJobRunner Contained in helloWorld.jar
java -jar helloWorld.jar jobs/helloWorld.xml helloWorldJob
You pass two parameters in: the path to the job's configuration and the name of the job to run.
Using the -next parameter (from Chapter 4), as shown in Listing 6-4, invokes any configured
JobParametersIncrementers .
Listing 6-4. Using the -next Parameter
java -jar helloWorld.jar jobs/helloWorld.xml helloWorldJob -next
Although Table 6-1 shows seven parameters are available for CommandLineJobRunner , this chapter
only covers the four you have for now. Later in this chapter, you revisit CommandLineJobRunner and see
how to stop, abandon, and restart jobs with it. For now, you move on to the other job runner that Spring
Batch provides: JobRegistryBackgroundJobRunner .
JobRegistryBackgroundJobRunner
JobRegistryBackgroundJobRunner actually isn't a job runner at all. You don't execute jobs through this
runner as you do CommandLineJobRunner . Instead, this class is intended to be used to bootstrap Spring
and build a JobRegistry for others to consume. In Chapter 5, you wrote your own version of a class that
has a similar function to bootstrap Spring and your jobs for the JMXJobRunner .
But you didn't have to write your own.
org.springframework.batch.core.launch.support.JobRegistryBackgroundJobRunner is a command-line
interface, like CommandLineJobRunner . However, instead of running a job that is specified, this job runner
takes a list of configuration files. Once the configuration files have been bootstrapped,
JobRegistryBackgroundJobRunner pauses until a key is pressed.
Let's look at an example of how this works. To start, back to the JMXJobRunner example from Chapter
5. Up to now, you've linked the job XML file ( <project_home>/src/main/resources/jobs/helloWorld.xml )
with the main or parent application context ( <project_home>/src/main/resources/launch-context.xml ).
When using a JobRegistry, however, this isn't typically the case. The reason is that when a JobRegistry is
loaded, the jobs aren't executed immediately. Instead, you load all possible jobs that can be executed
into a Map that so they can be launched at any time. To configure your job correctly, you need to remove
a single line: the import of the launch-context.xml file in the helloWorld.xml file. You do this to prevent a
circular reference. If you leave the reference to the launch-context.xml file in your helloWorld.xml file,
the JobRegistryBackgroundJobRunner will load launch-context.xml and then load the jobs in
helloWorld.xml . Because launch-context.xml is already loaded at that point, you don't want or need to
load it again.
The other modification you need to do is to remove the AutomaticJobRegistrar bean from launch-
context.xml . JobRegistryBackgroundJobRunner takes two parameters from the command line: a base
configuration (called the parent ) that contains all general components including things like the
JobRepository , JobLauncher , and so on; and a list of configuration files containing the jobs you want to
run. JobRegistryBackgroundJobRunner registers the jobs it finds in the configuration you pass, so there is
no need for AutomaticJobRegistrar .