Tweak wording in Job identity section

src/site/docbook/reference/domain.xml

@@ -107,14 +107,14 @@
     namespace abstracts away the need to instantiate it directly. Instead, the
     <code>&lt;job&gt;</code> tag can be used:</para>
 
-    <programlisting>  
-  &lt;job id="footballJob"&gt;
-    &lt;step id="playerload" next="gameLoad"/&gt;
-    &lt;step id="gameLoad" next="playerSummarization"/&gt;
-    &lt;step id="playerSummarization"/&gt;
-  &lt;/job&gt;
+    <programlisting><![CDATA[  
+  <job id="footballJob">
+    <step id="playerload" next="gameLoad"/>
+    <step id="gameLoad" next="playerSummarization"/>
+    <step id="playerSummarization"/>
+  </job>
 
-</programlisting>
+]]></programlisting>
 
     <section id="jobInstance">
       <title id="s.2.1.2">JobInstance</title>
@@ -133,10 +133,13 @@
       Therefore, each <classname>JobInstance</classname> can have multiple
       executions (<classname>JobExecution</classname> is discussed in more
       detail below) and only one <classname>JobInstance</classname>
-      corresponding to a particular <classname>Job</classname> can be running
-      at a given time. The definition of a <classname>JobInstance</classname>
-      has absolutely no bearing on the data the will be loaded. It is entirely
-      up to the <classname>ItemReader</classname> implementation used to
+      corresponding to a particular <classname>Job</classname> and
+      <classname>JobParameters</classname> can be running at a given time.
+      </para>
+
+      <para>The definition of a <classname>JobInstance</classname> has
+      absolutely no bearing on the data the will be loaded. It is entirely up
+      to the <classname>ItemReader</classname> implementation used to
       determine how data will be loaded. For example, in the EndOfDay
       scenario, there may be a column on the data that indicates the
       'effective date' or 'schedule date' to which the data belongs. So, the
@@ -713,7 +716,7 @@
     is to put the current number of lines read into the context, and the
     framework will do the rest:</para>
 
-    <programlisting>executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());</programlisting>
+    <programlisting><![CDATA[executionContext.putLong(getKey(LINES_READ_COUNT), reader.getPosition());]]></programlisting>
 
     <para>Using the EndOfDay example from the Job Stereotypes section as an
     example, assume there's one step: 'loadData', that loads a file into the
@@ -860,7 +863,7 @@
     <classname>ItemReader</classname> is opened, it can check to see if it has
     any stored state in the context, and initialize itself from there:</para>
 
-    <programlisting>  if (executionContext.containsKey(getKey(LINES_READ_COUNT))) {
+    <programlisting><![CDATA[  if (executionContext.containsKey(getKey(LINES_READ_COUNT))) {
     log.debug("Initializing for restart. Restart data is: " + executionContext);
 
     long lineCount = executionContext.getLong(getKey(LINES_READ_COUNT));
@@ -868,10 +871,10 @@
     LineReader reader = getReader();
 
     Object record = "";
-    while (reader.getPosition() &lt; lineCount &amp;&amp; record != null) {
+    while (reader.getPosition() < lineCount && record != null) {
        record = readLine();
     }
-  }</programlisting>
+  }]]></programlisting>
 
     <para>In this case, after the above code is executed, the current line
     will be 40,322, allowing the <classname>Step</classname> to start again
@@ -911,12 +914,12 @@
     <classname>StepExecution</classname>. For example, consider the following
     code snippet:</para>
 
-    <programlisting>
+    <programlisting><![CDATA[
   ExecutionContext ecStep = stepExecution.getExecutionContext();
   ExecutionContext ecJob = jobExecution.getExecutionContext();
   //ecStep does not equal ecJob
 
-</programlisting>
+]]></programlisting>
 
     <para>As noted in the comment, ecStep will not equal ecJob; they are two
     different <classname>ExecutionContext</classname>s. The one scoped to the
@@ -939,10 +942,10 @@
     <classname>JobExecution</classname> implementations are persisted by
     passing them to the repository:</para>
 
-    <programlisting>  
-  &lt;job-repository id="jobRepository"/&gt;
+    <programlisting><![CDATA[  
+  <job-repository id="jobRepository"/>
 
-</programlisting>
+]]></programlisting>
   </section>
 
   <section>
@@ -952,12 +955,12 @@
     launching a <classname>Job</classname> with a given set of
     <classname>JobParameters</classname>:</para>
 
-    <programlisting>  public interface JobLauncher {
+    <programlisting><![CDATA[  public interface JobLauncher {
 
     public JobExecution run(Job job, JobParameters jobParameters) 
                 throws JobExecutionAlreadyRunningException, JobRestartException;
 }
-</programlisting>
+]]></programlisting>
 
     <para>It is expected that implementations will obtain a valid
     <classname>JobExecution</classname> from the
@@ -1033,4 +1036,4 @@
     linkend="configureJob" />. More information on configuring a Step can be
     found in <xref linkend="configureStep" />.</para>
   </section>
-</chapter>
+</chapter>

src/site/docbook/reference/job.xml

@@ -73,7 +73,7 @@
       <classname>JobInstance</classname>. Ideally, all jobs should be able to
       start up where they left off, but there are scenarios where this is not
       possible. <emphasis role="bold">It is entirely up to the developer to
-      ensure that a new JobInstance is created in this scenario</emphasis>.
+      ensure that a new <classname>JobInstance</classname> is created in this scenario</emphasis>.
       However, Spring Batch does provide some help. If a
       <classname>Job</classname> should never be restarted, but should always
       be run as part of a new <classname>JobInstance</classname>, then the