Figure 5-5. The JMXJobRunner.runJob method exposed in JConsole
When you click the Runjob button, you see in the console in which you're currently running your
Java process that the job runs, giving you the output you expect with helloWorldJob .
2010-12-17 17:06:09,444 DEBUG RMI TCP Connection(1)-192.168.1.119
[org.springframework.batch.core.scope.context.StepContextRepeatCallback] - <Chunk execution
starting: queue size=0>
2010-12-17 17:06:09,450 DEBUG RMI TCP Connection(1)-192.168.1.119
[org.springframework.batch.core.step.tasklet.TaskletStep] - <Applying contribution:
[StepContribution: read=0, written=0, filtered=0, readSkips=0, writeSkips=0, processSkips=0,
In this example, you wrote a job runner that you were able to expose via JMX. Other uses would be
to develop a step listener that stops the job based on a given condition. In Chapter 6, you expand this
example to accept parameters and use the JobOperator to stop and restart jobs programmatically.
Spring Batch's ability to manage metadata about a job as well as maintain the state of the job as it runs
for error handling is one of the primary reasons, if not the primary reason, to use Spring Batch for
enterprise batch processing. Not only does it provide the ability for robust error handling, but it also
allows processes to make decisions about what to do based on what has happened elsewhere in the job.
In the next chapter, you put this metadata to further use as well as the JobOperator as you take a deep
look at how to start, stop, and restart jobs in a variety of environments.