Since the 2.0 release of Spring Batch, the Spring Data project has brought support for the NoSQL movement to Spring. The 2.2 release of Spring Batch has added support for MongoDB, Neo4j and Gemfire natively through the Spring Data abstractions.

This release has also added support for writing to any custom Spring Data Repository a user may write. The RepositoryItemReader and RepositoryItemWriter each wrap a repository implementation ( PagingAndSortingRepository and CrudRepository respectively) to retrieve data from and persist data to.

Until 2.2.0 the only option for configuring a job was via XML (either through the batch DSL or by hand). However, in 2.2.0, Java based configuration has been added as a way to define Spring Batch Jobs. To support this new configuration option, an annotation and builder classes have been added. What was previously defined as this:

<batch>
    <job-repository/>

    <job id="myJob">
        <step id="step1".../>
        <step id="step2".../>
    </job>

    <beans:bean id="transactionManager".../>

    <beans:bean id="jobLauncher" class="org.springframework.batch.core.launch.support.SimpleJobLauncher">
        <beans:property name="jobRepository" ref="jobRepository"/>
    </beans:bean>
</batch>
    

Can now be configured using the @EnableBatchProcessing annotation and the provided JobBuilderFactory and StepBuilderFactory as show below:

 @Configuration
 @EnableBatchProcessing
 @Import(DataSourceCnfiguration.class)
 public class AppConfig {

     @Autowired
      private JobBuilderFactory jobs;

     @Bean
     public Job job() {
          return jobs.get("myJob").start(step1()).next(step2()).build();
     }

     @Bean
     protected Step step1() {
          ...
     }

     @Bean
     protected Step step2() {
          ...
     }
}

The @EnableBatchProcessing annotation makes a number of common dependencies available for autowiring by default. This list includes a JobRepsitory, JobLauncher, JobRegistry, PlatformTransactionManager, JobBuilderFactory, and a StepBuilderFactory. More information on how to configure Jobs and Steps with the new Java config can be found in Section 4.2, “Java Config”

The ability to retry an operation via the RetryTemplate has always been a feature of Spring Batch. That ability has been identified as a useful feature for other frameworks (Spring Integration for example). With the 2.2.0 release, the retry logic has been extracted from Spring Batch into it's own library called Spring Retry. With this change, there are two main impacts. The first is that the majority of the org.springframework.batch.retry package has been moved into this new library. With that move, the package name has also dropped the batch to become org.springframework.retry.

Prior to the 2.2.0 release of Spring Batch, all parameters pass to a job execution were used as part of the identity of the job. This limited the ability to change job parameters during a rerun of a job. To accommodate this use case, 2.2.0 introduced the idea of non-identifying job parameters.

By default, job parameters in 2.2.0 are still identifying. However, Spring Batch now allows a user to specify a parameter not be used in the identity of a job instance. In order to support this change, the domain model for batch changed. Before 2.2.0, job parameters were associated with a JobInstance. 2.2.0 and beyond, they are associated with a JobExecution. This also required the underlying database schema for the job repository to change.