From ef2fedbcda5de38bd3e2f253e228daac593763e7 Mon Sep 17 00:00:00 2001 From: dsyer Date: Sun, 3 Jan 2010 10:38:41 +0000 Subject: [PATCH] BATCH-1474: added docs for JobLoader --- src/site/docbook/reference/job.xml | 78 +++++++++++++++++++++++++++--- 1 file changed, 71 insertions(+), 7 deletions(-) diff --git a/src/site/docbook/reference/job.xml b/src/site/docbook/reference/job.xml index 2c96b0318..15c14d01e 100644 --- a/src/site/docbook/reference/job.xml +++ b/src/site/docbook/reference/job.xml @@ -774,17 +774,81 @@ public class JobLauncherController { <bean id="jobRegistry" class="org.spr...MapJobRegistry" /> - A common use case is to use this registry together with a bean - post-processor that can register all jobs as they are created: + There are two ways to populate a JobRegistry automatically: using + a bean post processor and using a registrar lifecycle component. These + two mechanisms are described in the following sections. - <bean id="jobRegistryBeanPostProcessor" class="org.spr...JobRegistryBeanPostProcessor"> +
+ JobRegistryBeanPostProcessor + + This is a bean post-processor that can register all jobs as they + are created: + + <bean id="jobRegistryBeanPostProcessor" class="org.spr...JobRegistryBeanPostProcessor"> <property name="jobRegistry" ref="jobRegistry"/> </bean> - Athough it is not strictly necessary the post-processor in the - example has been given an id so that it can be included in child - contexts (e.g. as a parent bean definition) and cause all jobs created - there to also be regsistered automatically. + Athough it is not strictly necessary the post-processor in the + example has been given an id so that it can be included in child + contexts (e.g. as a parent bean definition) and cause all jobs created + there to also be regsistered automatically. +
+ +
+ AutomaticJobRegistrar + + This is a lifecycle component that creates child contexts and + registers jobs from those contexts as they are created. One advantage + of doing this is that, while the job names in the child contexts still + have to be globally unique in the registry, their dependencies can + have "natural" names. So for example, you can create a set of XML + configuration files each having only one Job, + but all having different definitions of an + ItemReader with the same bean name, e.g. + "reader". If all those files were imported into the same context, the + reader definitions would clash and override one another, but with the + automatic regsistrar this is avoided. This makes it easier to + integrate jobs contributed from separate modules of an + application. + + <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> + + The registrar has two mandatory properties, one is an array of + ApplicationContextFactory (here created from a + convenient factory bean), and the other is a + JobLoader. The JobLoader + is responsible for managing the lifecycle of the child contexts and + registering jobs in the JobRegistry. + + The ApplicationContextFactory is + responsible for creating the child context and the most common usage + would be as above using a + ClassPathXmlApplicationContextFactory. One of + the features of this factory is that by default it copies some of the + configuration down from the parent context to the child. So for + instance you don't have to re-define the + PropertyPlaceholderConfigurer or AOP + configuration in the child, if it should be the same as the + parent. + + The AutomaticJobRegistrar can be used in + conjunction with a JobRegistryBeanPostProcessor + if desired (as long as the DefaultJobLoader is + used as well). For instance this might be desirable if there are jobs + defined in the main parent context as well as in the child + locations. +