Spring Batch 2.1.8 中文文档(九)

4.5 Advanced Meta-Data usage

到目前为止，已经讨论了JobLauncher和JobRepository接口，它们展示了简单启动任务，以及批处理领域对象的基本CRUD操作：

一个JobLauncher使用一个JobRepository创建并运行新的JobExection对象，Job和Step实现随后使用相同的JobRepository在job运行期间去更新相同的JobExecution对象。这些基本的操作能够满足简单场景的需要，但是对于有着数百个任务和复杂定时流程的大型批处理情况来说，就需要使用更高级的方式访问元数据：

接下去会讨论JobExplorer和JobOperator两个接口，能够使用更多的功能去查询和修改元数据。

4.5.1 Querying the Repository

在使用高级功能之前，需要最基本的方法来查询repository去获取已经存在的execution。JobExplored接口提供了这些功能：

public interface JobExplorer {    List<JobInstance> getJobInstances(String jobName, int start, int count);    JobExecution getJobExecution(Long executionId);    StepExecution getStepExecution(Long jobExecutionId, Long stepExecutionId);    JobInstance getJobInstance(Long instanceId);    List<JobExecution> getJobExecutions(JobInstance jobInstance);    Set<JobExecution> findRunningJobExecutions(String jobName);}

上面的代码表示的很明显，JobExplorer是一个只读版的JobRepository，同JobRepository一样，它也能够很容易配置一个工厂类：

bean id="jobExplorer" class="org.spr...JobExplorerFactoryBean" p:dataSource-ref="dataSource" />

之前有提到过，JobRepository能够配置不同的表前缀用来支持不同的版本或是schema。JobExplorer也支持同样的特性：

<bean id="jobExplorer" class="org.spr...JobExplorerFactoryBean" p:dataSource-ref="dataSource" p:tablePrefix="BATCH_" />

4.5.2 JobRegistry

JobRegistry(父接口为JobLocator)并非强制使用，它能够协助用户在上下文中追踪job是否可用，也能够在应用上下文收集在其他地方(子上下文)创建的job信息。自定义的JobRegistry实现常被用于操作job的名称或是其他属性。框架提供了一个基于map的默认实现，能够从job的名称映射到job的实例：

<bean id="jobRegistry" class="org.spr...MapJobRegistry" />

有两种方法自动注册job进JobRegistry：使用bean的post处理器或是使用注册生命周期组件。这两种机制在下面描述。

4.5.2.1 JobRegistryBeanPostProcessor

这是post处理器，能够将job在创建时自动注册进JobRegistry：

<bean id="jobRegistryBeanPostProcessor" class="org.spr...JobRegistryBeanPostProcessor">    <property name="jobRegistry" ref="jobRegistry"/></bean>

并不一定要像例子中给post处理器一个id，但是使用id可以在子context中也使用post处理器，这样所有的job在创建时都会自动注册进JobRegistry。

4.5.2.2 AutomaticJobRegistry

这是生命周期组件，用于创建子context以及注册这些子context中的job。这种做法有一个好处，虽然job的名字仍然要求全局唯一，但是job的依赖项可以不用全局唯一有一个“自然”的名字。例如，创建了一组xml配置文件，每个文件有一个job，每个job的ItemReader都有一个相同的名字(如"reader")，如果这些文件被导入到一个上下文中，reader的定义会冲突并且互相覆盖。如果使用了自动注册机就能避免这一切发生。这样集成几个不同的应用模块就变得更容易了：

<bean class="org.spr...AutomaticJobRegistrar">   <property name="applicationContextFactories">      <bean class="org.spr...ClasspathXmlApplicationContextsFactoryBean">         <property name="resources" value="classpath*:/config/job*.xml" />      </bean>   </property>   <property name="jobLoader">      <bean class="org.spr...DefaultJobLoader">         <property name="jobRegistry" ref="jobRegistry" />      </bean>   </property></bean>

注册机有两个主要的属性，一个是ApplicationContextFactory数组(这儿创建了一个简单的factory bean)，另一个是jobLoader。JobLoader负责管理子context的生命周期以及注册任务到JobRegistry。
ApplicationContextFactory负责创建子Context，大多数情况下像上面那样使用ClassPathXmlApplicationContextFactory。这个工厂类的一个特性是默认情况下他会复制父上下文的一些配置到子上下文。因此如果不变的情况下不需要重新定义子上下文中的PropertyPlaceholderConfigurer和AOP配置。

在必要情况下，AutomaticJobRegistrar可以和JobRegistyBeanPostProcessor一起使用。例如，可能有job既定义在父上下文中也定义在子上下文中的情况