12. JSR-352 Support

Spring Batch and JSR-352 are structurally the same. They both have jobs that are made up of steps. They both have readers, processors, writers, and listeners. However, their interactions are subtly different. For example, the org.springframework.batch.core.SkipListener#onSkipInWrite(S item, Throwable t) within Spring Batch receives two parameters: the item that was skipped and the Exception that caused the skip. The JSR-352 version of the same method (javax.batch.api.chunk.listener.SkipWriteListener#onSkipWriteItem(List<Object> items, Exception ex)) also receives two parameters. However the first one is a List of all the items within the current chunk with the second being the Exception that caused the skip. Because of these differences, it is important to note that there are two paths to execute a job within Spring Batch: either a traditional Spring Batch job or a JSR-352 based job. While the use of Spring Batch artifacts (readers, writers, etc) will work within a job configured via JSR-352's JSL and executed via the JsrJobOperator, they will behave according to the rules of JSR-352. It is also important to note that batch artifacts that have been developed against the JSR-352 interfaces will not work within a traditional Spring Batch job.

JSR-352 is based heavily on the Spring Batch programming model. As such, while not explicitly requiring a formal dependency injection implementation, DI of some kind implied. Spring Batch supports all three methods for loading batch artifacts defined by JSR-352:

To use Spring dependency injection within a JSR-352 based batch job consists of configuring batch artifacts using a Spring application context as beans. Once the beans have been defined, a job can refer to them as it would any bean defined within the batch.xml.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://www.springframework.org/schema/beans
                              http://www.springframework.org/schema/beans/spring-beans.xsd
                              http://xmlns.jcp.org/xml/ns/javaee
                              http://xmlns.jcp.org/xml/ns/javaee/jobXML_1_0.xsd">

    <!-- javax.batch.api.Batchlet implementation -->
    <bean id="fooBatchlet" class="io.spring.FooBatchlet">
            <property name="prop" value="bar"/>
    </bean>

    <!-- Job is defined using the JSL schema provided in JSR-352 -->
    <job id="fooJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
        <step id="step1">
            <batchlet ref="fooBatchlet"/>
        </step>
    </job>
</beans>
        

The assembly of Spring contexts (imports, etc) works with JSR-352 jobs just as it would with any other Spring based application. The only difference with a JSR-352 based job is that the entry point for the context definition will be the job definition found in /META-INF/batch-jobs/.

To use the thread context class loader approach, all you need to do is provide the fully qualified class name as the ref. It is important to note that when using this approach or the batch.xml approach, the class referenced requires a no argument constructor which will be used to create the bean.

<?xml version="1.0" encoding="UTF-8"?>
<job id="fooJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
    <step id="step1" >
        <batchlet ref="io.spring.FooBatchlet" />
    </step>
</job>
        

JSR-352 provides the same two basic processing models that Spring Batch does:

...
<step id="step1">
    <chunk checkpoint-policy="item" item-count="3">
        <reader ref="fooReader"/>
        <processor ref="fooProcessor"/>
        <writer ref="fooWriter"/>
    </chunk>
</step>
...

...
<step id="step1">
    <chunk checkpoint-policy="custom">
        <checkpoint-algorithm ref="fooCheckpointer"/>
        <reader ref="fooReader"/>
        <processor ref="fooProcessor"/>
        <writer ref="fooWriter"/>
    </chunk>
</step>
...

The entrance to executing a JSR-352 based job is through the javax.batch.operations.JobOperator. Spring Batch provides our own implementation to this interface (org.springframework.batch.core.jsr.launch.JsrJobOperator). This implementation is loaded via the javax.batch.runtime.BatchRuntime. Launching a JSR-352 based batch job is implemented as follows:

JobOperator jobOperator = BatchRuntime.getJobOperator();
long jobExecutionId = jobOperator.start("fooJob", new Properties());
        

The above code does the following:

	Note
	All JSR-352 based batch jobs are executed asynchronously.

When JobOperator#start is called using SimpleJobOperator, Spring Batch determines if the call is an initial run or a retry of a previously executed run. Using the JSR-352 based JobOpeator#start(String jobXMLName, Properties jobParameters), the framework will always create a new JobInstance (JSR-352 job parameters are non-identifying). In order to restart a job, a call to JobOperator#restart(long executionId, Properties restartParameters) is required.

JSR-352 defines two context objects that are used to interact with the meta-data of a job or step from within a batch artifact: javax.batch.runtime.context.JobContext and javax.batch.runtime.context.StepContext. Both of these are available in any step level artifact (Batchlet, ItemReader, etc) with the JobContext being available to job level artifacts as well (JobListener for example).

To obtain a reference to the JobContext or StepContext within the current scope, simply use the @Inject annotation:

@Inject
JobContext jobContext;
        

	@Autowire for JSR-352 contexts
	Using Spring's @Autowire is not supported for the injection of these contexts.

In Spring Batch, the JobContext and StepContext wrap their corresponding execution objects (JobExecution and StepExecution respectively). Data stored via StepContext#persistent#setPersistentUserData(Serializable data) is stored in the Spring Batch StepExecution#executionContext.

Within a JSR-352 based job, the flow of steps works similarly as it does within Spring Batch. However, there are a few subtle differences:

Traditional Spring Batch jobs have four ways of scaling (the last two capable of being executed across multiple JVMs):

JSR-352 provides two options for scaling batch jobs. Both options support only a single JVM:

Since all JSR-352 based jobs are executed asynchronously, it can be difficult to determine when a job has completed. To help with testing, Spring Batch provides the org.springframework.batch.core.jsr.JsrTestUtils. This utility class provides the ability to start a job and restart a job and wait for it to complete. Once the job completes, the associated JobExecution is returned.