Chapter 4. Configuring and Running a Job
在领域章节，我们讨论了整体结构的设计，使用下图表示：
虽然一个job看上去只是许多step的简单容器，但是开发者必须要注意许多配置项。此外，job的运行以及job运行过程中元数据如何被保存也是需要考虑的。本章将会介绍job运行时的各种配置项。
4.1. Configuring a Job
job接口的实现方式有多个，但是在配置上命名空间存在着不同。必须依赖的只有三项：名称，JobRespository和step的列表：
[html] view plain copy
1. <job id="footballJob">
2. <step id="playerload" parent="s1" next="gameLoad"/>
3. <step id="gameLoad" parent="s2" next="playerSummarization"/>
4. <step id="playerSummarization" parent="s3"/>
5. </job>
这个例子是使用父bean定义来创建step，更多描述step配置的信息可以参考step configuration这一节。XML命名空间默认会使用id为'jobRepository'的引用来作为repository的定义。然而可以向如下显式的覆盖：
[html] view plain copy
1. <job id="footballJob" job-repository="specialRepository">
2. <step id="playerload" parent="s1" next="gameLoad"/>
3. <step id="gameLoad" parent="s3" next="playerSummarization"/>
4. <step id="playerSummarization" parent="s3"/>
5. </job> 此外，job配置的step还包含其他的元素，有并发处理(<split/>)，流程控制(<decision/>)和流程定义(<flow/>)。
4.1.1 Restartablity
执行批处理任务是一个关键问题是要考虑job被重启后的行为。如果一个JobExecution已经存在一个特定的JobInstance，那么这个job启动时可以认为是“重启”。理想情况下，所有任务都能够在他们中止的地方启动，但是有许多场景这是不可能的。在这种场景中就要有开发者来决定创建一个新的JobInstance，Spring对此也提供了一些帮助。如果job不需要重启，而是总是作为新的JobInstance来运行，那么可重启属性可以设置为'false'：
[html] view plain copy
1. <job id="footballJob" restartable="false">
2. ...
3. </job>
设置一个重启属性为‘false’表示‘这个job不支持再次启动’，重启一个不可重启的job会抛出JobRestartException：
[java] view plain copy
1. Job job = new
2. job.setRestartable(false);
3.
4. JobParameters jobParameters = new
5.
6. JobExecution firstExecution = jobRepository.createJobExecution(job, jobParameters);
7. jobRepository.saveOrUpdate(firstExecution);
8.
9. try
10. jobRepository.createJobExecution(job, jobParameters);
11. fail();
12. }
13. catch
14. // expected
15. }
这个JUnit代码展示了创建一个不可重启的Job后，第一次能够创建JobExecution，第二次再创建相同的JobExcution会抛出一个JobRestartException
4.1.2 Intercepting Job Execution
在job执行过程中，自定义代码能够在生命周期中通过事件通知执行会是很有用的。SimpleJob能够在合适的时机这样调用JobListener：
[java] view plain copy
1. public interface
2.
3. void
4.
5. void
6.
7. }
JobListener能够添加到SimpleJob中去，作为job的listener元素：
[java] view plain copy
1. <job id="footballJob">
2. "playerload" parent="s1" next="gameLoad"/>
3. "gameLoad" parent="s2" next="playerSummarization"/>
4. "playerSummarization" parent="s3"/>
5. <listeners>
6. "sampleListener"/>
7. </listeners>
8. </job> 无论job成功还是失败都会调用afterJob，可以从JobExecution中获取运行结果后根据结果来进行不同的处理：
[java] view plain copy
1. public void
2. if( jobExecution.getStatus() == BatchStatus.COMPLETED ){
3. //job success
4. }
5. else if(jobExecution.getStatus() == BatchStatus.FAILED){
6. //job failure
7. }
8. } 对应于这个interface的annotation为：
- @BeforeJob
- @AfterJob
4.1.3 Inheriting from a parent Job
如果一组job有着相似的配置，但又不是完全相同，那么可以定义一个"父”job，让这些job去继承属性。同Java的类继承一样，子job会把父job的属性和元素合并进来。
下面的例子中，“baseJob”是一个抽象的job定义，只定义了一个监听器列表。名为“job1”的job是一个具体定义，它继承了“baseJob"的监听器，并且与自己的监听器合并，最终生成的job带有两个监听器，以及一个名为”step1“的step。
[html] view plain copy
1. <job id="baseJob" abstract="true">
2. <listeners>
3. <listener ref="listenerOne"/>
4. <listeners>
5. </job>
6.
7. <job id="job1" parent="baseJob">
8. <step id="step1" parent="standaloneStep"/>
9.
10. <listeners merge="true">
11. <listener ref="listenerTwo"/>
12. <listeners>
13. </job> 参考”Inheriting from a Parent Step"可以获得更多信息。
4.1.4 JobParametersValidator
一个在xml命名空间描述的job或是使用任何抽象job子类的job，都能够为运行时为job参数定义一个验证器。在job启动时需要保证所有必填参数都存在的场景下，这个功能是很有用的。有一个DefaultJobParametersValidator可以用来限制一些简单的必选和可选参数组合，你也可以实现接口用来处理更复杂的限制。验证器的配置支持使用xml命名空间来作为job的子元素，例如：
[html] view plain copy
1. <job id="job1" parent="baseJob3">
2. <step id="step1" parent="standaloneStep"/>
3. <validator ref="paremetersValidator"/>
4. </job>
