#1 添加英文原文（2）

docs/en/spring-batch/appendix.md

+## Appendix A: List of ItemReaders and ItemWriters
+
+### Item Readers
+
+|              Item Reader               |                                                                                                                                                                                                                                                                                                   Description                                                                                                                                                                                                                                                                                                   |
+|----------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|AbstractItemCountingItemStreamItemReader|                                                                                                                                                                                                                                       Abstract base class that provides basic<br/>restart capabilities by counting the number of items returned from<br/>an `ItemReader`.                                                                                                                                                                                                                                       |
+|          AggregateItemReader           |An `ItemReader` that delivers a list as its<br/>item, storing up objects from the injected `ItemReader` until they<br/>are ready to be packed out as a collection. This class must be used<br/>as a wrapper for a custom `ItemReader` that can identify the record<br/>boundaries. The custom reader should mark the beginning and end of<br/>records by returning an `AggregateItem` which responds `true` to its<br/>query methods `isHeader()` and `isFooter()`. Note that this reader<br/>is not part of the library of readers provided by Spring Batch<br/>but given as a sample in `spring-batch-samples`.|
+|             AmqpItemReader             |                                                                                                                                                                                                                                 Given a Spring `AmqpTemplate`, it provides<br/>synchronous receive methods. The `receiveAndConvert()` method<br/>lets you receive POJO objects.                                                                                                                                                                                                                                 |
+|            KafkaItemReader             |                                                                                                                                                                             An `ItemReader` that reads messages from an Apache Kafka topic.<br/>It can be configured to read messages from multiple partitions of the same topic.<br/>This reader stores message offsets in the execution context to support restart capabilities.                                                                                                                                                                              |
+|           FlatFileItemReader           |                                                                                                                                                                                                                               Reads from a flat file. Includes `ItemStream`and `Skippable` functionality. See [`FlatFileItemReader`](readersAndWriters.html#flatFileItemReader).                                                                                                                                                                                                                                |
+|       HibernateCursorItemReader        |                                                                                                                                                                                                                                           Reads from a cursor based on an HQL query. See[`Cursor-based ItemReaders`](readersAndWriters.html#cursorBasedItemReaders).                                                                                                                                                                                                                                            |
+|       HibernatePagingItemReader        |                                                                                                                                                                                                                                                                                        Reads from a paginated HQL query                                                                                                                                                                                                                                                                                         |
+|           ItemReaderAdapter            |                                                                                                                                                                                                                                                                                 Adapts any class to the`ItemReader` interface.                                                                                                                                                                                                                                                                                  |
+|          JdbcCursorItemReader          |                                                                                                                                                                                                                                             Reads from a database cursor via JDBC. See[`Cursor-based ItemReaders`](readersAndWriters.html#cursorBasedItemReaders).                                                                                                                                                                                                                                              |
+|          JdbcPagingItemReader          |                                                                                                                                                                                                                                           Given an SQL statement, pages through the rows,<br/>such that large datasets can be read without running out of<br/>memory.                                                                                                                                                                                                                                           |
+|             JmsItemReader              |                                                                                                                                                                                                         Given a Spring `JmsOperations` object and a JMS<br/>Destination or destination name to which to send errors, provides items<br/>received through the injected `JmsOperations#receive()`method.                                                                                                                                                                                                          |
+|          JpaPagingItemReader           |                                                                                                                                                                                                                                           Given a JPQL statement, pages through the<br/>rows, such that large datasets can be read without running out of<br/>memory.                                                                                                                                                                                                                                           |
+|             ListItemReader             |                                                                                                                                                                                                                                                                               Provides the items from a list, one at a<br/>time.                                                                                                                                                                                                                                                                                |
+|            MongoItemReader             |                                                                                                                                                                                                                                     Given a `MongoOperations` object and a JSON-based MongoDB<br/>query, provides items received from the `MongoOperations#find()` method.                                                                                                                                                                                                                                      |
+|            Neo4jItemReader             |                                                                                                                                                                                                                              Given a `Neo4jOperations` object and the components of a<br/>Cyhper query, items are returned as the result of the Neo4jOperations.query<br/>method.                                                                                                                                                                                                                               |
+|          RepositoryItemReader          |                                                                                                                                                                                                               Given a Spring Data `PagingAndSortingRepository` object,<br/>a `Sort`, and the name of method to execute, returns items provided by the<br/>Spring Data repository implementation.                                                                                                                                                                                                                |
+|       StoredProcedureItemReader        |                                                                                                                                                                                                                Reads from a database cursor resulting from the<br/>execution of a database stored procedure. See [`StoredProcedureItemReader`](readersAndWriters.html#StoredProcedureItemReader)                                                                                                                                                                                                                |
+|          StaxEventItemReader           |                                                                                                                                                                                                                                                            Reads via StAX. see [`StaxEventItemReader`](readersAndWriters.html#StaxEventItemReader).                                                                                                                                                                                                                                                             |
+|             JsonItemReader             |                                                                                                                                                                                                                                                        Reads items from a Json document. see [`JsonItemReader`](readersAndWriters.html#JsonItemReader).                                                                                                                                                                                                                                                         |
+
+### Item Writers
+
+|             Item Writer              |                                                                                                                            Description                                                                                                                            |
+|--------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+|     AbstractItemStreamItemWriter     |                                                                                           Abstract base class that combines the`ItemStream` and`ItemWriter` interfaces.                                                                                           |
+|            AmqpItemWriter            |                                                          Given a Spring `AmqpTemplate`, it provides<br/>for a synchronous `send` method. The `convertAndSend(Object)`method lets you send POJO objects.                                                           |
+|         CompositeItemWriter          |                                                                                  Passes an item to the `write` method of each<br/>in an injected `List` of `ItemWriter` objects.                                                                                  |
+|          FlatFileItemWriter          |                                                       Writes to a flat file. Includes `ItemStream` and<br/>Skippable functionality. See [`FlatFileItemWriter`](readersAndWriters.html#flatFileItemWriter).                                                        |
+|          GemfireItemWriter           |                                                     Using a `GemfireOperations` object, items are either written<br/>or removed from the Gemfire instance based on the configuration of the delete<br/>flag.                                                      |
+|         HibernateItemWriter          |            This item writer is Hibernate-session aware<br/>and handles some transaction-related work that a non-"hibernate-aware"<br/>item writer would not need to know about and then delegates<br/>to another item writer to do the actual writing.            |
+|          ItemWriterAdapter           |                                                                                                          Adapts any class to the`ItemWriter` interface.                                                                                                           |
+|         JdbcBatchItemWriter          |                                                              Uses batching features from a`PreparedStatement`, if available, and can<br/>take rudimentary steps to locate a failure during a`flush`.                                                              |
+|            JmsItemWriter             |                                                                  Using a `JmsOperations` object, items are written<br/>to the default queue through the `JmsOperations#convertAndSend()` method.                                                                  |
+|            JpaItemWriter             |                   This item writer is JPA EntityManager-aware<br/>and handles some transaction-related work that a non-"JPA-aware"`ItemWriter` would not need to know about and<br/>then delegates to another writer to do the actual writing.                    |
+|           KafkaItemWriter            |Using a `KafkaTemplate` object, items are written to the default topic through the`KafkaTemplate#sendDefault(Object, Object)` method using a `Converter` to map the key from the item.<br/>A delete flag can also be configured to send delete events to the topic.|
+|        MimeMessageItemWriter         |                                                                                      Using Spring’s `JavaMailSender`, items of type `MimeMessage`are sent as mail messages.                                                                                       |
+|           MongoItemWriter            |                             Given a `MongoOperations` object, items are written<br/>through the `MongoOperations.save(Object)` method. The actual write is delayed<br/>until the last possible moment before the transaction commits.                             |
+|           Neo4jItemWriter            |                                                Given a `Neo4jOperations` object, items are persisted through the`save(Object)` method or deleted through the `delete(Object)` per the`ItemWriter’s` configuration                                                 |
+|PropertyExtractingDelegatingItemWriter|       Extends `AbstractMethodInvokingDelegator`creating arguments on the fly. Arguments are created by retrieving<br/>the values from the fields in the item to be processed (through a`SpringBeanWrapper`), based on an injected array of field<br/>names.       |
+|         RepositoryItemWriter         |                                                                    Given a Spring Data `CrudRepository` implementation,<br/>items are saved through the method specified in the configuration.                                                                    |
+|         StaxEventItemWriter          |                                                                       Uses a `Marshaller` implementation to<br/>convert each item to XML and then writes it to an XML file using<br/>StAX.                                                                        |
+|          JsonFileItemWriter          |                                                                         Uses a `JsonObjectMarshaller` implementation to<br/>convert each item to Json and then writes it to an Json file.
\ No newline at end of file

docs/en/spring-batch/glossary.md

+# Glossary
+
+## Appendix A: Glossary
+
+### Spring Batch Glossary
+
+Batch
+
+An accumulation of business transactions over time.
+
+Batch Application Style
+
+Term used to designate batch as an application style in its own right, similar to
+online, Web, or SOA. It has standard elements of input, validation, transformation of
+information to business model, business processing, and output. In addition, it
+requires monitoring at a macro level.
+
+Batch Processing
+
+The handling of a batch of many business transactions that have accumulated over a
+period of time (such as an hour, a day, a week, a month, or a year). It is the
+application of a process or set of processes to many data entities or objects in a
+repetitive and predictable fashion with either no manual element or a separate manual
+element for error processing.
+
+Batch Window
+
+The time frame within which a batch job must complete. This can be constrained by other
+systems coming online, other dependent jobs needing to execute, or other factors
+specific to the batch environment.
+
+Step
+
+The main batch task or unit of work. It initializes the business logic and controls the
+transaction environment, based on commit interval setting and other factors.
+
+Tasklet
+
+A component created by an application developer to process the business logic for a
+Step.
+
+Batch Job Type
+
+Job types describe application of jobs for particular types of processing. Common areas
+are interface processing (typically flat files), forms processing (either for online
+PDF generation or print formats), and report processing.
+
+Driving Query
+
+A driving query identifies the set of work for a job to do. The job then breaks that
+work into individual units of work. For instance, a driving query might be to identify
+all financial transactions that have a status of "pending transmission" and send them
+to a partner system. The driving query returns a set of record IDs to process. Each
+record ID then becomes a unit of work. A driving query may involve a join (if the
+criteria for selection falls across two or more tables) or it may work with a single
+table.
+
+Item
+
+An item represents the smallest amount of complete data for processing. In the simplest
+terms, this might be a line in a file, a row in a database table, or a particular
+element in an XML file.
+
+Logical Unit of Work (LUW)
+
+A batch job iterates through a driving query (or other input source, such as a file) to
+perform the set of work that the job must accomplish. Each iteration of work performed
+is a unit of work.
+
+Commit Interval
+
+A set of LUWs processed within a single transaction.
+
+Partitioning
+
+Splitting a job into multiple threads where each thread is responsible for a subset of
+the overall data to be processed. The threads of execution may be within the same JVM
+or they may span JVMs in a clustered environment that supports workload balancing.
+
+Staging Table
+
+A table that holds temporary data while it is being processed.
+
+Restartable
+
+A job that can be executed again and assumes the same identity as when run initially.
+In other words, it is has the same job instance ID.
+
+Rerunnable
+
+A job that is restartable and manages its own state in terms of the previous run’s
+record processing. An example of a rerunnable step is one based on a driving query. If
+the driving query can be formed so that it limits the processed rows when the job is
+restarted, then it is re-runnable. This is managed by the application logic. Often, a
+condition is added to the `where` statement to limit the rows returned by the driving
+query with logic resembling "and processedFlag!= true".
+
+Repeat
+
+One of the most basic units of batch processing, it defines by repeatability calling a
+portion of code until it is finished and while there is no error. Typically, a batch
+process would be repeatable as long as there is input.
+
+Retry
+
+Simplifies the execution of operations with retry semantics most frequently associated
+with handling transactional output exceptions. Retry is slightly different from repeat,
+rather than continually calling a block of code, retry is stateful and continually
+calls the same block of code with the same input, until it either succeeds or some type
+of retry limit has been exceeded. It is only generally useful when a subsequent
+invocation of the operation might succeed because something in the environment has
+improved.
+
+Recover
+
+Recover operations handle an exception in such a way that a repeat process is able to
+continue.
+
+Skip
+
+Skip is a recovery strategy often used on file input sources as the strategy for
+ignoring bad input records that failed validation.
\ No newline at end of file

docs/en/spring-batch/monitoring-and-metrics.md

+# Monitoring and metrics
+
+## Monitoring and metrics
+
+Since version 4.2, Spring Batch provides support for batch monitoring and metrics
+based on [Micrometer](https://micrometer.io/). This section describes
+which metrics are provided out-of-the-box and how to contribute custom metrics.
+
+### Built-in metrics
+
+Metrics collection does not require any specific configuration. All metrics provided
+by the framework are registered in[Micrometer’s global registry](https://micrometer.io/docs/concepts#_global_registry)under the `spring.batch` prefix. The following table explains all the metrics in details:
+
+|       *Metric Name*       |     *Type*      |       *Description*       |             *Tags*              |
+|---------------------------|-----------------|---------------------------|---------------------------------|
+|    `spring.batch.job`     |     `TIMER`     | Duration of job execution |        `name`, `status`         |
+| `spring.batch.job.active` |`LONG_TASK_TIMER`|   Currently active jobs   |             `name`              |
+|    `spring.batch.step`    |     `TIMER`     |Duration of step execution |  `name`, `job.name`, `status`   |
+| `spring.batch.item.read`  |     `TIMER`     | Duration of item reading  |`job.name`, `step.name`, `status`|
+|`spring.batch.item.process`|     `TIMER`     |Duration of item processing|`job.name`, `step.name`, `status`|
+|`spring.batch.chunk.write` |     `TIMER`     | Duration of chunk writing |`job.name`, `step.name`, `status`|
+
+|   |The `status` tag can be either `SUCCESS` or `FAILURE`.|
+|---|------------------------------------------------------|
+
+### Custom metrics
+
+If you want to use your own metrics in your custom components, we recommend using
+Micrometer APIs directly. The following is an example of how to time a `Tasklet`:
+
+```
+import io.micrometer.core.instrument.Metrics;
+import io.micrometer.core.instrument.Timer;
+
+import org.springframework.batch.core.StepContribution;
+import org.springframework.batch.core.scope.context.ChunkContext;
+import org.springframework.batch.core.step.tasklet.Tasklet;
+import org.springframework.batch.repeat.RepeatStatus;
+
+public class MyTimedTasklet implements Tasklet {
+
+	@Override
+	public RepeatStatus execute(StepContribution contribution, ChunkContext chunkContext) {
+		Timer.Sample sample = Timer.start(Metrics.globalRegistry);
+		String status = "success";
+		try {
+			// do some work
+		} catch (Exception e) {
+			// handle exception
+			status = "failure";
+		} finally {
+			sample.stop(Timer.builder("my.tasklet.timer")
+					.description("Duration of MyTimedTasklet")
+					.tag("status", status)
+					.register(Metrics.globalRegistry));
+		}
+		return RepeatStatus.FINISHED;
+	}
+}
+```
+
+### Disabling metrics
+
+Metrics collection is a concern similar to logging. Disabling logs is typically
+done by configuring the logging library and this is no different for metrics.
+There is no feature in Spring Batch to disable micrometer’s metrics, this should
+be done on micrometer’s side. Since Spring Batch stores metrics in the global
+registry of micrometer with the `spring.batch` prefix, it is possible to configure
+micrometer to ignore/deny batch metrics with the following snippet:
+
+```
+Metrics.globalRegistry.config().meterFilter(MeterFilter.denyNameStartsWith("spring.batch"))
+```
+
+Please refer to micrometer’s [reference documentation](http://micrometer.io/docs/concepts#_meter_filters)for more details.
\ No newline at end of file

docs/en/spring-batch/processor.md

+# Item processing
+
+## Item processing
+
+XMLJavaBoth
+
+The [ItemReader and ItemWriter interfaces](readersAndWriters.html#readersAndWriters) are both very useful for their specific
+tasks, but what if you want to insert business logic before writing? One option for both
+reading and writing is to use the composite pattern: Create an `ItemWriter` that contains
+another `ItemWriter` or an `ItemReader` that contains another `ItemReader`. The following
+code shows an example:
+
+```
+public class CompositeItemWriter<T> implements ItemWriter<T> {
+
+    ItemWriter<T> itemWriter;
+
+    public CompositeItemWriter(ItemWriter<T> itemWriter) {
+        this.itemWriter = itemWriter;
+    }
+
+    public void write(List<? extends T> items) throws Exception {
+        //Add business logic here
+       itemWriter.write(items);
+    }
+
+    public void setDelegate(ItemWriter<T> itemWriter){
+        this.itemWriter = itemWriter;
+    }
+}
+```
+
+The preceding class contains another `ItemWriter` to which it delegates after having
+provided some business logic. This pattern could easily be used for an `ItemReader` as
+well, perhaps to obtain more reference data based upon the input that was provided by the
+main `ItemReader`. It is also useful if you need to control the call to `write` yourself.
+However, if you only want to 'transform' the item passed in for writing before it is
+actually written, you need not `write` yourself. You can just modify the item. For this
+scenario, Spring Batch provides the `ItemProcessor` interface, as shown in the following
+interface definition:
+
+```
+public interface ItemProcessor<I, O> {
+
+    O process(I item) throws Exception;
+}
+```
+
+An `ItemProcessor` is simple. Given one object, transform it and return another. The
+provided object may or may not be of the same type. The point is that business logic may
+be applied within the process, and it is completely up to the developer to create that
+logic. An `ItemProcessor` can be wired directly into a step. For example, assume an`ItemReader` provides a class of type `Foo` and that it needs to be converted to type `Bar`before being written out. The following example shows an `ItemProcessor` that performs
+the conversion:
+
+```
+public class Foo {}
+
+public class Bar {
+    public Bar(Foo foo) {}
+}
+
+public class FooProcessor implements ItemProcessor<Foo, Bar> {
+    public Bar process(Foo foo) throws Exception {
+        //Perform simple transformation, convert a Foo to a Bar
+        return new Bar(foo);
+    }
+}
+
+public class BarWriter implements ItemWriter<Bar> {
+    public void write(List<? extends Bar> bars) throws Exception {
+        //write bars
+    }
+}
+```
+
+In the preceding example, there is a class `Foo`, a class `Bar`, and a class`FooProcessor` that adheres to the `ItemProcessor` interface. The transformation is
+simple, but any type of transformation could be done here. The `BarWriter` writes `Bar`objects, throwing an exception if any other type is provided. Similarly, the`FooProcessor` throws an exception if anything but a `Foo` is provided. The`FooProcessor` can then be injected into a `Step`, as shown in the following example:
+
+XML Configuration
+
+```
+<job id="ioSampleJob">
+    <step name="step1">
+        <tasklet>
+            <chunk reader="fooReader" processor="fooProcessor" writer="barWriter"
+                   commit-interval="2"/>
+        </tasklet>
+    </step>
+</job>
+```
+
+Java Configuration
+
+```
+@Bean
+public Job ioSampleJob() {
+	return this.jobBuilderFactory.get("ioSampleJob")
+				.start(step1())
+				.build();
+}
+
+@Bean
+public Step step1() {
+	return this.stepBuilderFactory.get("step1")
+				.<Foo, Bar>chunk(2)
+				.reader(fooReader())
+				.processor(fooProcessor())
+				.writer(barWriter())
+				.build();
+}
+```
+
+A difference between `ItemProcessor` and `ItemReader` or `ItemWriter` is that an `ItemProcessor`is optional for a `Step`.
+
+### Chaining ItemProcessors
+
+Performing a single transformation is useful in many scenarios, but what if you want to
+'chain' together multiple `ItemProcessor` implementations? This can be accomplished using
+the composite pattern mentioned previously. To update the previous, single
+transformation, example, `Foo` is transformed to `Bar`, which is transformed to `Foobar`and written out, as shown in the following example:
+
+```
+public class Foo {}
+
+public class Bar {
+    public Bar(Foo foo) {}
+}
+
+public class Foobar {
+    public Foobar(Bar bar) {}
+}
+
+public class FooProcessor implements ItemProcessor<Foo, Bar> {
+    public Bar process(Foo foo) throws Exception {
+        //Perform simple transformation, convert a Foo to a Bar
+        return new Bar(foo);
+    }
+}
+
+public class BarProcessor implements ItemProcessor<Bar, Foobar> {
+    public Foobar process(Bar bar) throws Exception {
+        return new Foobar(bar);
+    }
+}
+
+public class FoobarWriter implements ItemWriter<Foobar>{
+    public void write(List<? extends Foobar> items) throws Exception {
+        //write items
+    }
+}
+```
+
+A `FooProcessor` and a `BarProcessor` can be 'chained' together to give the resultant`Foobar`, as shown in the following example:
+
+```
+CompositeItemProcessor<Foo,Foobar> compositeProcessor =
+                                      new CompositeItemProcessor<Foo,Foobar>();
+List itemProcessors = new ArrayList();
+itemProcessors.add(new FooProcessor());
+itemProcessors.add(new BarProcessor());
+compositeProcessor.setDelegates(itemProcessors);
+```
+
+Just as with the previous example, the composite processor can be configured into the`Step`:
+
+XML Configuration
+
+```
+<job id="ioSampleJob">
+    <step name="step1">
+        <tasklet>
+            <chunk reader="fooReader" processor="compositeItemProcessor" writer="foobarWriter"
+                   commit-interval="2"/>
+        </tasklet>
+    </step>
+</job>
+
+<bean id="compositeItemProcessor"
+      class="org.springframework.batch.item.support.CompositeItemProcessor">
+    <property name="delegates">
+        <list>
+            <bean class="..FooProcessor" />
+            <bean class="..BarProcessor" />
+        </list>
+    </property>
+</bean>
+```
+
+Java Configuration
+
+```
+@Bean
+public Job ioSampleJob() {
+	return this.jobBuilderFactory.get("ioSampleJob")
+				.start(step1())
+				.build();
+}
+
+@Bean
+public Step step1() {
+	return this.stepBuilderFactory.get("step1")
+				.<Foo, Foobar>chunk(2)
+				.reader(fooReader())
+				.processor(compositeProcessor())
+				.writer(foobarWriter())
+				.build();
+}
+
+@Bean
+public CompositeItemProcessor compositeProcessor() {
+	List<ItemProcessor> delegates = new ArrayList<>(2);
+	delegates.add(new FooProcessor());
+	delegates.add(new BarProcessor());
+
+	CompositeItemProcessor processor = new CompositeItemProcessor();
+
+	processor.setDelegates(delegates);
+
+	return processor;
+}
+```
+
+### Filtering Records
+
+One typical use for an item processor is to filter out records before they are passed to
+the `ItemWriter`. Filtering is an action distinct from skipping. Skipping indicates that
+a record is invalid, while filtering simply indicates that a record should not be
+written.
+
+For example, consider a batch job that reads a file containing three different types of
+records: records to insert, records to update, and records to delete. If record deletion
+is not supported by the system, then we would not want to send any "delete" records to
+the `ItemWriter`. But, since these records are not actually bad records, we would want to
+filter them out rather than skip them. As a result, the `ItemWriter` would receive only
+"insert" and "update" records.
+
+To filter a record, you can return `null` from the `ItemProcessor`. The framework detects
+that the result is `null` and avoids adding that item to the list of records delivered to
+the `ItemWriter`. As usual, an exception thrown from the `ItemProcessor` results in a
+skip.
+
+### Validating Input
+
+In the [ItemReaders and ItemWriters](readersAndWriters.html#readersAndWriters) chapter, multiple approaches to parsing input have been
+discussed. Each major implementation throws an exception if it is not 'well-formed'. The`FixedLengthTokenizer` throws an exception if a range of data is missing. Similarly,
+attempting to access an index in a `RowMapper` or `FieldSetMapper` that does not exist or
+is in a different format than the one expected causes an exception to be thrown. All of
+these types of exceptions are thrown before `read` returns. However, they do not address
+the issue of whether or not the returned item is valid. For example, if one of the fields
+is an age, it obviously cannot be negative. It may parse correctly, because it exists and
+is a number, but it does not cause an exception. Since there are already a plethora of
+validation frameworks, Spring Batch does not attempt to provide yet another. Rather, it
+provides a simple interface, called `Validator`, that can be implemented by any number of
+frameworks, as shown in the following interface definition:
+
+```
+public interface Validator<T> {
+
+    void validate(T value) throws ValidationException;
+
+}
+```
+
+The contract is that the `validate` method throws an exception if the object is invalid
+and returns normally if it is valid. Spring Batch provides an out of the box`ValidatingItemProcessor`, as shown in the following bean definition:
+
+XML Configuration
+
+```
+<bean class="org.springframework.batch.item.validator.ValidatingItemProcessor">
+    <property name="validator" ref="validator" />
+</bean>
+
+<bean id="validator" class="org.springframework.batch.item.validator.SpringValidator">
+	<property name="validator">
+		<bean class="org.springframework.batch.sample.domain.trade.internal.validator.TradeValidator"/>
+	</property>
+</bean>
+```
+
+Java Configuration
+
+```
+@Bean
+public ValidatingItemProcessor itemProcessor() {
+	ValidatingItemProcessor processor = new ValidatingItemProcessor();
+
+	processor.setValidator(validator());
+
+	return processor;
+}
+
+@Bean
+public SpringValidator validator() {
+	SpringValidator validator = new SpringValidator();
+
+	validator.setValidator(new TradeValidator());
+
+	return validator;
+}
+```
+
+You can also use the `BeanValidatingItemProcessor` to validate items annotated with
+the Bean Validation API (JSR-303) annotations. For example, given the following type `Person`:
+
+```
+class Person {
+
+    @NotEmpty
+    private String name;
+
+    public Person(String name) {
+     this.name = name;
+    }
+
+    public String getName() {
+     return name;
+    }
+
+    public void setName(String name) {
+     this.name = name;
+    }
+
+}
+```
+
+you can validate items by declaring a `BeanValidatingItemProcessor` bean in your
+application context and register it as a processor in your chunk-oriented step:
+
+```
+@Bean
+public BeanValidatingItemProcessor<Person> beanValidatingItemProcessor() throws Exception {
+    BeanValidatingItemProcessor<Person> beanValidatingItemProcessor = new BeanValidatingItemProcessor<>();
+    beanValidatingItemProcessor.setFilter(true);
+
+    return beanValidatingItemProcessor;
+}
+```
+
+### Fault Tolerance
+
+When a chunk is rolled back, items that have been cached during reading may be
+reprocessed. If a step is configured to be fault tolerant (typically by using skip or
+retry processing), any `ItemProcessor` used should be implemented in a way that is
+idempotent. Typically that would consist of performing no changes on the input item for
+the `ItemProcessor` and only updating the
+instance that is the result.
\ No newline at end of file

docs/en/spring-batch/repeat.md

+# Repeat
+
+## Repeat
+
+XMLJavaBoth
+
+### RepeatTemplate
+
+Batch processing is about repetitive actions, either as a simple optimization or as part
+of a job. To strategize and generalize the repetition and to provide what amounts to an
+iterator framework, Spring Batch has the `RepeatOperations` interface. The`RepeatOperations` interface has the following definition:
+
+```
+public interface RepeatOperations {
+
+    RepeatStatus iterate(RepeatCallback callback) throws RepeatException;
+
+}
+```
+
+The callback is an interface, shown in the following definition, that lets you insert
+some business logic to be repeated:
+
+```
+public interface RepeatCallback {
+
+    RepeatStatus doInIteration(RepeatContext context) throws Exception;
+
+}
+```
+
+The callback is executed repeatedly until the implementation determines that the
+iteration should end. The return value in these interfaces is an enumeration that can
+either be `RepeatStatus.CONTINUABLE` or `RepeatStatus.FINISHED`. A `RepeatStatus`enumeration conveys information to the caller of the repeat operations about whether
+there is any more work to do. Generally speaking, implementations of `RepeatOperations`should inspect the `RepeatStatus` and use it as part of the decision to end the
+iteration. Any callback that wishes to signal to the caller that there is no more work to
+do can return `RepeatStatus.FINISHED`.
+
+The simplest general purpose implementation of `RepeatOperations` is `RepeatTemplate`, as
+shown in the following example:
+
+```
+RepeatTemplate template = new RepeatTemplate();
+
+template.setCompletionPolicy(new SimpleCompletionPolicy(2));
+
+template.iterate(new RepeatCallback() {
+
+    public RepeatStatus doInIteration(RepeatContext context) {
+        // Do stuff in batch...
+        return RepeatStatus.CONTINUABLE;
+    }
+
+});
+```
+
+In the preceding example, we return `RepeatStatus.CONTINUABLE`, to show that there is
+more work to do. The callback can also return `RepeatStatus.FINISHED`, to signal to the
+caller that there is no more work to do. Some iterations can be terminated by
+considerations intrinsic to the work being done in the callback. Others are effectively
+infinite loops as far as the callback is concerned and the completion decision is
+delegated to an external policy, as in the case shown in the preceding example.
+
+#### RepeatContext
+
+The method parameter for the `RepeatCallback` is a `RepeatContext`. Many callbacks ignore
+the context. However, if necessary, it can be used as an attribute bag to store transient
+data for the duration of the iteration. After the `iterate` method returns, the context
+no longer exists.
+
+If there is a nested iteration in progress, a `RepeatContext` has a parent context. The
+parent context is occasionally useful for storing data that need to be shared between
+calls to `iterate`. This is the case, for instance, if you want to count the number of
+occurrences of an event in the iteration and remember it across subsequent calls.
+
+#### RepeatStatus
+
+`RepeatStatus` is an enumeration used by Spring Batch to indicate whether processing has
+finished. It has two possible `RepeatStatus` values, described in the following table:
+
+|  *Value*  |            *Description*             |
+|-----------|--------------------------------------|
+|CONTINUABLE|      There is more work to do.       |
+| FINISHED  |No more repetitions should take place.|
+
+`RepeatStatus` values can also be combined with a logical AND operation by using the`and()` method in `RepeatStatus`. The effect of this is to do a logical AND on the
+continuable flag. In other words, if either status is `FINISHED`, then the result is`FINISHED`.
+
+### Completion Policies
+
+Inside a `RepeatTemplate`, the termination of the loop in the `iterate` method is
+determined by a `CompletionPolicy`, which is also a factory for the `RepeatContext`. The`RepeatTemplate` has the responsibility to use the current policy to create a`RepeatContext` and pass that in to the `RepeatCallback` at every stage in the iteration.
+After a callback completes its `doInIteration`, the `RepeatTemplate` has to make a call
+to the `CompletionPolicy` to ask it to update its state (which will be stored in the`RepeatContext`). Then it asks the policy if the iteration is complete.
+
+Spring Batch provides some simple general purpose implementations of `CompletionPolicy`.`SimpleCompletionPolicy` allows execution up to a fixed number of times (with`RepeatStatus.FINISHED` forcing early completion at any time).
+
+Users might need to implement their own completion policies for more complicated
+decisions. For example, a batch processing window that prevents batch jobs from executing
+once the online systems are in use would require a custom policy.
+
+### Exception Handling
+
+If there is an exception thrown inside a `RepeatCallback`, the `RepeatTemplate` consults
+an `ExceptionHandler`, which can decide whether or not to re-throw the exception.
+
+The following listing shows the `ExceptionHandler` interface definition:
+
+```
+public interface ExceptionHandler {
+
+    void handleException(RepeatContext context, Throwable throwable)
+        throws Throwable;
+
+}
+```
+
+A common use case is to count the number of exceptions of a given type and fail when a
+limit is reached. For this purpose, Spring Batch provides the`SimpleLimitExceptionHandler` and a slightly more flexible`RethrowOnThresholdExceptionHandler`. The `SimpleLimitExceptionHandler` has a limit
+property and an exception type that should be compared with the current exception. All
+subclasses of the provided type are also counted. Exceptions of the given type are
+ignored until the limit is reached, and then they are rethrown. Exceptions of other types
+are always rethrown.
+
+An important optional property of the `SimpleLimitExceptionHandler` is the boolean flag
+called `useParent`. It is `false` by default, so the limit is only accounted for in the
+current `RepeatContext`. When set to `true`, the limit is kept across sibling contexts in
+a nested iteration (such as a set of chunks inside a step).
+
+### Listeners
+
+Often, it is useful to be able to receive additional callbacks for cross-cutting concerns
+across a number of different iterations. For this purpose, Spring Batch provides the`RepeatListener` interface. The `RepeatTemplate` lets users register `RepeatListener`implementations, and they are given callbacks with the `RepeatContext` and `RepeatStatus`where available during the iteration.
+
+The `RepeatListener` interface has the following definition:
+
+```
+public interface RepeatListener {
+    void before(RepeatContext context);
+    void after(RepeatContext context, RepeatStatus result);
+    void open(RepeatContext context);
+    void onError(RepeatContext context, Throwable e);
+    void close(RepeatContext context);
+}
+```
+
+The `open` and `close` callbacks come before and after the entire iteration. `before`,`after`, and `onError` apply to the individual `RepeatCallback` calls.
+
+Note that, when there is more than one listener, they are in a list, so there is an
+order. In this case, `open` and `before` are called in the same order while `after`,`onError`, and `close` are called in reverse order.
+
+### Parallel Processing
+
+Implementations of `RepeatOperations` are not restricted to executing the callback
+sequentially. It is quite important that some implementations are able to execute their
+callbacks in parallel. To this end, Spring Batch provides the`TaskExecutorRepeatTemplate`, which uses the Spring `TaskExecutor` strategy to run the`RepeatCallback`. The default is to use a `SynchronousTaskExecutor`, which has the effect
+of executing the whole iteration in the same thread (the same as a normal`RepeatTemplate`).
+
+### Declarative Iteration
+
+Sometimes there is some business processing that you know you want to repeat every time
+it happens. The classic example of this is the optimization of a message pipeline. It is
+more efficient to process a batch of messages, if they are arriving frequently, than to
+bear the cost of a separate transaction for every message. Spring Batch provides an AOP
+interceptor that wraps a method call in a `RepeatOperations` object for just this
+purpose. The `RepeatOperationsInterceptor` executes the intercepted method and repeats
+according to the `CompletionPolicy` in the provided `RepeatTemplate`.
+
+The following example shows declarative iteration using the Spring AOP namespace to
+repeat a service call to a method called `processMessage` (for more detail on how to
+configure AOP interceptors, see the Spring User Guide):
+
+```
+<aop:config>
+    <aop:pointcut id="transactional"
+        expression="execution(* com..*Service.processMessage(..))" />
+    <aop:advisor pointcut-ref="transactional"
+        advice-ref="retryAdvice" order="-1"/>
+</aop:config>
+
+<bean id="retryAdvice" class="org.spr...RepeatOperationsInterceptor"/>
+```
+
+The following example demonstrates using Java configuration to
+repeat a service call to a method called `processMessage` (for more detail on how to
+configure AOP interceptors, see the Spring User Guide):
+
+```
+@Bean
+public MyService myService() {
+	ProxyFactory factory = new ProxyFactory(RepeatOperations.class.getClassLoader());
+	factory.setInterfaces(MyService.class);
+	factory.setTarget(new MyService());
+
+	MyService service = (MyService) factory.getProxy();
+	JdkRegexpMethodPointcut pointcut = new JdkRegexpMethodPointcut();
+	pointcut.setPatterns(".*processMessage.*");
+
+	RepeatOperationsInterceptor interceptor = new RepeatOperationsInterceptor();
+
+	((Advised) service).addAdvisor(new DefaultPointcutAdvisor(pointcut, interceptor));
+
+	return service;
+}
+```
+
+The preceding example uses a default `RepeatTemplate` inside the interceptor. To change
+the policies, listeners, and other details, you can inject an instance of`RepeatTemplate` into the interceptor.
+
+If the intercepted method returns `void`, then the interceptor always returns`RepeatStatus.CONTINUABLE` (so there is a danger of an infinite loop if the`CompletionPolicy` does not have a finite end point). Otherwise, it returns`RepeatStatus.CONTINUABLE` until the return value from the intercepted method is `null`,
+at which point it returns `RepeatStatus.FINISHED`. Consequently, the business logic
+inside the target method can signal that there is no more work to do by returning `null`or by throwing an exception that is re-thrown by the `ExceptionHandler` in the provided`RepeatTemplate`.

docs/en/spring-batch/retry.md

+# Retry
+
+## Retry
+
+XMLJavaBoth
+
+To make processing more robust and less prone to failure, it sometimes helps to
+automatically retry a failed operation in case it might succeed on a subsequent attempt.
+Errors that are susceptible to intermittent failure are often transient in nature.
+Examples include remote calls to a web service that fails because of a network glitch or a`DeadlockLoserDataAccessException` in a database update.
+
+### `RetryTemplate`
+
+|   |The retry functionality was pulled out of Spring Batch as of 2.2.0.<br/>It is now part of a new library, [Spring Retry](https://github.com/spring-projects/spring-retry).|
+|---|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+To automate retry operations Spring Batch has the `RetryOperations` strategy. The
+following interface definition for `RetryOperations`:
+
+```
+public interface RetryOperations {
+
+    <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback) throws E;
+
+    <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback, RecoveryCallback<T> recoveryCallback)
+        throws E;
+
+    <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback, RetryState retryState)
+        throws E, ExhaustedRetryException;
+
+    <T, E extends Throwable> T execute(RetryCallback<T, E> retryCallback, RecoveryCallback<T> recoveryCallback,
+        RetryState retryState) throws E;
+
+}
+```
+
+The basic callback is a simple interface that lets you insert some business logic to be
+retried, as shown in the following interface definition:
+
+```
+public interface RetryCallback<T, E extends Throwable> {
+
+    T doWithRetry(RetryContext context) throws E;
+
+}
+```
+
+The callback runs and, if it fails (by throwing an `Exception`), it is retried until
+either it is successful or the implementation aborts. There are a number of overloaded`execute` methods in the `RetryOperations` interface. Those methods deal with various use
+cases for recovery when all retry attempts are exhausted and deal with retry state, which
+lets clients and implementations store information between calls (we cover this in more
+detail later in the chapter).
+
+The simplest general purpose implementation of `RetryOperations` is `RetryTemplate`. It
+can be used as follows:
+
+```
+RetryTemplate template = new RetryTemplate();
+
+TimeoutRetryPolicy policy = new TimeoutRetryPolicy();
+policy.setTimeout(30000L);
+
+template.setRetryPolicy(policy);
+
+Foo result = template.execute(new RetryCallback<Foo>() {
+
+    public Foo doWithRetry(RetryContext context) {
+        // Do stuff that might fail, e.g. webservice operation
+        return result;
+    }
+
+});
+```
+
+In the preceding example, we make a web service call and return the result to the user. If
+that call fails, then it is retried until a timeout is reached.
+
+#### `RetryContext`
+
+The method parameter for the `RetryCallback` is a `RetryContext`. Many callbacks ignore
+the context, but, if necessary, it can be used as an attribute bag to store data for the
+duration of the iteration.
+
+A `RetryContext` has a parent context if there is a nested retry in progress in the same
+thread. The parent context is occasionally useful for storing data that need to be shared
+between calls to `execute`.
+
+#### `RecoveryCallback`
+
+When a retry is exhausted, the `RetryOperations` can pass control to a different callback,
+called the `RecoveryCallback`. To use this feature, clients pass in the callbacks together
+to the same method, as shown in the following example:
+
+```
+Foo foo = template.execute(new RetryCallback<Foo>() {
+    public Foo doWithRetry(RetryContext context) {
+        // business logic here
+    },
+  new RecoveryCallback<Foo>() {
+    Foo recover(RetryContext context) throws Exception {
+          // recover logic here
+    }
+});
+```
+
+If the business logic does not succeed before the template decides to abort, then the
+client is given the chance to do some alternate processing through the recovery callback.
+
+#### Stateless Retry
+
+In the simplest case, a retry is just a while loop. The `RetryTemplate` can just keep
+trying until it either succeeds or fails. The `RetryContext` contains some state to
+determine whether to retry or abort, but this state is on the stack and there is no need
+to store it anywhere globally, so we call this stateless retry. The distinction between
+stateless and stateful retry is contained in the implementation of the `RetryPolicy` (the`RetryTemplate` can handle both). In a stateless retry, the retry callback is always
+executed in the same thread it was on when it failed.
+
+#### Stateful Retry
+
+Where the failure has caused a transactional resource to become invalid, there are some
+special considerations. This does not apply to a simple remote call because there is no
+transactional resource (usually), but it does sometimes apply to a database update,
+especially when using Hibernate. In this case it only makes sense to re-throw the
+exception that called the failure immediately, so that the transaction can roll back and
+we can start a new, valid transaction.
+
+In cases involving transactions, a stateless retry is not good enough, because the
+re-throw and roll back necessarily involve leaving the `RetryOperations.execute()` method
+and potentially losing the context that was on the stack. To avoid losing it we have to
+introduce a storage strategy to lift it off the stack and put it (at a minimum) in heap
+storage. For this purpose, Spring Batch provides a storage strategy called`RetryContextCache`, which can be injected into the `RetryTemplate`. The default
+implementation of the `RetryContextCache` is in memory, using a simple `Map`. Advanced
+usage with multiple processes in a clustered environment might also consider implementing
+the `RetryContextCache` with a cluster cache of some sort (however, even in a clustered
+environment, this might be overkill).
+
+Part of the responsibility of the `RetryOperations` is to recognize the failed operations
+when they come back in a new execution (and usually wrapped in a new transaction). To
+facilitate this, Spring Batch provides the `RetryState` abstraction. This works in
+conjunction with a special `execute` methods in the `RetryOperations` interface.
+
+The way the failed operations are recognized is by identifying the state across multiple
+invocations of the retry. To identify the state, the user can provide a `RetryState`object that is responsible for returning a unique key identifying the item. The identifier
+is used as a key in the `RetryContextCache` interface.
+
+|   |Be very careful with the implementation of `Object.equals()` and `Object.hashCode()` in<br/>the key returned by `RetryState`. The best advice is to use a business key to identify the<br/>items. In the case of a JMS message, the message ID can be used.|
+|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+When the retry is exhausted, there is also the option to handle the failed item in a
+different way, instead of calling the `RetryCallback` (which is now presumed to be likely
+to fail). Just like in the stateless case, this option is provided by the`RecoveryCallback`, which can be provided by passing it in to the `execute` method of`RetryOperations`.
+
+The decision to retry or not is actually delegated to a regular `RetryPolicy`, so the
+usual concerns about limits and timeouts can be injected there (described later in this
+chapter).
+
+### Retry Policies
+
+Inside a `RetryTemplate`, the decision to retry or fail in the `execute` method is
+determined by a `RetryPolicy`, which is also a factory for the `RetryContext`. The`RetryTemplate` has the responsibility to use the current policy to create a`RetryContext` and pass that in to the `RetryCallback` at every attempt. After a callback
+fails, the `RetryTemplate` has to make a call to the `RetryPolicy` to ask it to update its
+state (which is stored in the `RetryContext`) and then asks the policy if another attempt
+can be made. If another attempt cannot be made (such as when a limit is reached or a
+timeout is detected) then the policy is also responsible for handling the exhausted state.
+Simple implementations throw `RetryExhaustedException`, which causes any enclosing
+transaction to be rolled back. More sophisticated implementations might attempt to take
+some recovery action, in which case the transaction can remain intact.
+
+|   |Failures are inherently either retryable or not. If the same exception is always going to<br/>be thrown from the business logic, it does no good to retry it. So do not retry on all<br/>exception types. Rather, try to focus on only those exceptions that you expect to be<br/>retryable. It is not usually harmful to the business logic to retry more aggressively, but<br/>it is wasteful, because, if a failure is deterministic, you spend time retrying something<br/>that you know in advance is fatal.|
+|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+Spring Batch provides some simple general purpose implementations of stateless`RetryPolicy`, such as `SimpleRetryPolicy` and `TimeoutRetryPolicy` (used in the preceding example).
+
+The `SimpleRetryPolicy` allows a retry on any of a named list of exception types, up to a
+fixed number of times. It also has a list of "fatal" exceptions that should never be
+retried, and this list overrides the retryable list so that it can be used to give finer
+control over the retry behavior, as shown in the following example:
+
+```
+SimpleRetryPolicy policy = new SimpleRetryPolicy();
+// Set the max retry attempts
+policy.setMaxAttempts(5);
+// Retry on all exceptions (this is the default)
+policy.setRetryableExceptions(new Class[] {Exception.class});
+// ... but never retry IllegalStateException
+policy.setFatalExceptions(new Class[] {IllegalStateException.class});
+
+// Use the policy...
+RetryTemplate template = new RetryTemplate();
+template.setRetryPolicy(policy);
+template.execute(new RetryCallback<Foo>() {
+    public Foo doWithRetry(RetryContext context) {
+        // business logic here
+    }
+});
+```
+
+There is also a more flexible implementation called `ExceptionClassifierRetryPolicy`,
+which lets the user configure different retry behavior for an arbitrary set of exception
+types though the `ExceptionClassifier` abstraction. The policy works by calling on the
+classifier to convert an exception into a delegate `RetryPolicy`. For example, one
+exception type can be retried more times before failure than another by mapping it to a
+different policy.
+
+Users might need to implement their own retry policies for more customized decisions. For
+instance, a custom retry policy makes sense when there is a well-known, solution-specific
+classification of exceptions into retryable and not retryable.
+
+### Backoff Policies
+
+When retrying after a transient failure, it often helps to wait a bit before trying again,
+because usually the failure is caused by some problem that can only be resolved by
+waiting. If a `RetryCallback` fails, the `RetryTemplate` can pause execution according to
+the `BackoffPolicy`.
+
+The following code shows the interface definition for the `BackOffPolicy` interface:
+
+```
+public interface BackoffPolicy {
+
+    BackOffContext start(RetryContext context);
+
+    void backOff(BackOffContext backOffContext)
+        throws BackOffInterruptedException;
+
+}
+```
+
+A `BackoffPolicy` is free to implement the backOff in any way it chooses. The policies
+provided by Spring Batch out of the box all use `Object.wait()`. A common use case is to
+backoff with an exponentially increasing wait period, to avoid two retries getting into
+lock step and both failing (this is a lesson learned from ethernet). For this purpose,
+Spring Batch provides the `ExponentialBackoffPolicy`.
+
+### Listeners
+
+Often, it is useful to be able to receive additional callbacks for cross cutting concerns
+across a number of different retries. For this purpose, Spring Batch provides the`RetryListener` interface. The `RetryTemplate` lets users register `RetryListeners`, and
+they are given callbacks with `RetryContext` and `Throwable` where available during the
+iteration.
+
+The following code shows the interface definition for `RetryListener`:
+
+```
+public interface RetryListener {
+
+    <T, E extends Throwable> boolean open(RetryContext context, RetryCallback<T, E> callback);
+
+    <T, E extends Throwable> void onError(RetryContext context, RetryCallback<T, E> callback, Throwable throwable);
+
+    <T, E extends Throwable> void close(RetryContext context, RetryCallback<T, E> callback, Throwable throwable);
+}
+```
+
+The `open` and `close` callbacks come before and after the entire retry in the simplest
+case, and `onError` applies to the individual `RetryCallback` calls. The `close` method
+might also receive a `Throwable`. If there has been an error, it is the last one thrown by
+the `RetryCallback`.
+
+Note that, when there is more than one listener, they are in a list, so there is an order.
+In this case, `open` is called in the same order while `onError` and `close` are called in
+reverse order.
+
+### Declarative Retry
+
+Sometimes, there is some business processing that you know you want to retry every time it
+happens. The classic example of this is the remote service call. Spring Batch provides an
+AOP interceptor that wraps a method call in a `RetryOperations` implementation for just
+this purpose. The `RetryOperationsInterceptor` executes the intercepted method and retries
+on failure according to the `RetryPolicy` in the provided `RepeatTemplate`.
+
+The following example shows a declarative retry that uses the Spring AOP namespace to
+retry a service call to a method called `remoteCall` (for more detail on how to configure
+AOP interceptors, see the Spring User Guide):
+
+```
+<aop:config>
+    <aop:pointcut id="transactional"
+        expression="execution(* com..*Service.remoteCall(..))" />
+    <aop:advisor pointcut-ref="transactional"
+        advice-ref="retryAdvice" order="-1"/>
+</aop:config>
+
+<bean id="retryAdvice"
+    class="org.springframework.retry.interceptor.RetryOperationsInterceptor"/>
+```
+
+The following example shows a declarative retry that uses java configuration to retry a
+service call to a method called `remoteCall` (for more detail on how to configure AOP
+interceptors, see the Spring User Guide):
+
+```
+@Bean
+public MyService myService() {
+	ProxyFactory factory = new ProxyFactory(RepeatOperations.class.getClassLoader());
+	factory.setInterfaces(MyService.class);
+	factory.setTarget(new MyService());
+
+	MyService service = (MyService) factory.getProxy();
+	JdkRegexpMethodPointcut pointcut = new JdkRegexpMethodPointcut();
+	pointcut.setPatterns(".*remoteCall.*");
+
+	RetryOperationsInterceptor interceptor = new RetryOperationsInterceptor();
+
+	((Advised) service).addAdvisor(new DefaultPointcutAdvisor(pointcut, interceptor));
+
+	return service;
+}
+```
+
+The preceding example uses a default `RetryTemplate` inside the interceptor. To change the
+policies or listeners, you can inject an instance of `RetryTemplate` into the interceptor.
\ No newline at end of file

docs/en/spring-batch/testing.md

+# Unit Testing
+
+## Unit Testing
+
+XMLJavaBoth
+
+As with other application styles, it is extremely important to unit test any code written
+as part of a batch job. The Spring core documentation covers how to unit and integration
+test with Spring in great detail, so it is not be repeated here. It is important, however,
+to think about how to 'end to end' test a batch job, which is what this chapter covers.
+The spring-batch-test project includes classes that facilitate this end-to-end test
+approach.
+
+### Creating a Unit Test Class
+
+In order for the unit test to run a batch job, the framework must load the job’s
+ApplicationContext. Two annotations are used to trigger this behavior:
+
+* `@RunWith(SpringJUnit4ClassRunner.class)`: Indicates that the class should use Spring’s
+  JUnit facilities
+
+* `@ContextConfiguration(…​)`: Indicates which resources to configure the`ApplicationContext` with.
+
+Starting from v4.1, it is also possible to inject Spring Batch test utilities
+like the `JobLauncherTestUtils` and `JobRepositoryTestUtils` in the test context
+using the `@SpringBatchTest` annotation.
+
+|   |It should be noted that `JobLauncherTestUtils` requires a `Job` bean and that`JobRepositoryTestUtils` requires a `DataSource` bean. Since `@SpringBatchTest`registers a `JobLauncherTestUtils` and a `JobRepositoryTestUtils` in the test<br/>context, it is expected that the test context contains a single autowire candidate<br/>for a `Job` and a `DataSource` (either a single bean definition or one that is<br/>annotated with `org.springframework.context.annotation.Primary`).|
+|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+
+The following Java example shows the annotations in use:
+
+Using Java Configuration
+
+```
+@SpringBatchTest
+@RunWith(SpringRunner.class)
+@ContextConfiguration(classes=SkipSampleConfiguration.class)
+public class SkipSampleFunctionalTests { ... }
+```
+
+The following XML example shows the annotations in use:
+
+Using XML Configuration
+
+```
+@SpringBatchTest
+@RunWith(SpringRunner.class)
+@ContextConfiguration(locations = { "/simple-job-launcher-context.xml",
+                                    "/jobs/skipSampleJob.xml" })
+public class SkipSampleFunctionalTests { ... }
+```
+
+### End-To-End Testing of Batch Jobs
+
+'End To End' testing can be defined as testing the complete run of a batch job from
+beginning to end. This allows for a test that sets up a test condition, executes the job,
+and verifies the end result.
+
+Consider an example of a batch job that reads from the database and writes to a flat file.
+The test method begins by setting up the database with test data. It clears the CUSTOMER
+table and then inserts 10 new records. The test then launches the `Job` by using the`launchJob()` method. The `launchJob()` method is provided by the `JobLauncherTestUtils`class. The `JobLauncherTestUtils` class also provides the `launchJob(JobParameters)`method, which allows the test to give particular parameters. The `launchJob()` method
+returns the `JobExecution` object, which is useful for asserting particular information
+about the `Job` run. In the following case, the test verifies that the `Job` ended with
+status "COMPLETED".
+
+The following listing shows the example in XML:
+
+XML Based Configuration
+
+```
+@SpringBatchTest
+@RunWith(SpringRunner.class)
+@ContextConfiguration(locations = { "/simple-job-launcher-context.xml",
+                                    "/jobs/skipSampleJob.xml" })
+public class SkipSampleFunctionalTests {
+
+    @Autowired
+    private JobLauncherTestUtils jobLauncherTestUtils;
+
+    private SimpleJdbcTemplate simpleJdbcTemplate;
+
+    @Autowired
+    public void setDataSource(DataSource dataSource) {
+        this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
+    }
+
+    @Test
+    public void testJob() throws Exception {
+        simpleJdbcTemplate.update("delete from CUSTOMER");
+        for (int i = 1; i <= 10; i++) {
+            simpleJdbcTemplate.update("insert into CUSTOMER values (?, 0, ?, 100000)",
+                                      i, "customer" + i);
+        }
+
+        JobExecution jobExecution = jobLauncherTestUtils.launchJob();
+
+        Assert.assertEquals("COMPLETED", jobExecution.getExitStatus().getExitCode());
+    }
+}
+```
+
+The following listing shows the example in Java:
+
+Java Based Configuration
+
+```
+@SpringBatchTest
+@RunWith(SpringRunner.class)
+@ContextConfiguration(classes=SkipSampleConfiguration.class)
+public class SkipSampleFunctionalTests {
+
+    @Autowired
+    private JobLauncherTestUtils jobLauncherTestUtils;
+
+    private SimpleJdbcTemplate simpleJdbcTemplate;
+
+    @Autowired
+    public void setDataSource(DataSource dataSource) {
+        this.simpleJdbcTemplate = new SimpleJdbcTemplate(dataSource);
+    }
+
+    @Test
+    public void testJob() throws Exception {
+        simpleJdbcTemplate.update("delete from CUSTOMER");
+        for (int i = 1; i <= 10; i++) {
+            simpleJdbcTemplate.update("insert into CUSTOMER values (?, 0, ?, 100000)",
+                                      i, "customer" + i);
+        }
+
+        JobExecution jobExecution = jobLauncherTestUtils.launchJob();
+
+        Assert.assertEquals("COMPLETED", jobExecution.getExitStatus().getExitCode());
+    }
+}
+```
+
+### Testing Individual Steps
+
+For complex batch jobs, test cases in the end-to-end testing approach may become
+unmanageable. It these cases, it may be more useful to have test cases to test individual
+steps on their own. The `AbstractJobTests` class contains a method called `launchStep`,
+which takes a step name and runs just that particular `Step`. This approach allows for
+more targeted tests letting the test set up data for only that step and to validate its
+results directly. The following example shows how to use the `launchStep` method to load a`Step` by name:
+
+```
+JobExecution jobExecution = jobLauncherTestUtils.launchStep("loadFileStep");
+```
+
+### Testing Step-Scoped Components
+
+Often, the components that are configured for your steps at runtime use step scope and
+late binding to inject context from the step or job execution. These are tricky to test as
+standalone components, unless you have a way to set the context as if they were in a step
+execution. That is the goal of two components in Spring Batch:`StepScopeTestExecutionListener` and `StepScopeTestUtils`.
+
+The listener is declared at the class level, and its job is to create a step execution
+context for each test method, as shown in the following example:
+
+```
+@ContextConfiguration
+@TestExecutionListeners( { DependencyInjectionTestExecutionListener.class,
+    StepScopeTestExecutionListener.class })
+@RunWith(SpringRunner.class)
+public class StepScopeTestExecutionListenerIntegrationTests {
+
+    // This component is defined step-scoped, so it cannot be injected unless
+    // a step is active...
+    @Autowired
+    private ItemReader<String> reader;
+
+    public StepExecution getStepExecution() {
+        StepExecution execution = MetaDataInstanceFactory.createStepExecution();
+        execution.getExecutionContext().putString("input.data", "foo,bar,spam");
+        return execution;
+    }
+
+    @Test
+    public void testReader() {
+        // The reader is initialized and bound to the input data
+        assertNotNull(reader.read());
+    }
+
+}
+```
+
+There are two `TestExecutionListeners`. One is the regular Spring Test framework, which
+handles dependency injection from the configured application context to inject the reader.
+The other is the Spring Batch `StepScopeTestExecutionListener`. It works by looking for a
+factory method in the test case for a `StepExecution`, using that as the context for the
+test method, as if that execution were active in a `Step` at runtime. The factory method
+is detected by its signature (it must return a `StepExecution`). If a factory method is
+not provided, then a default `StepExecution` is created.
+
+Starting from v4.1, the `StepScopeTestExecutionListener` and`JobScopeTestExecutionListener` are imported as test execution listeners
+if the test class is annotated with `@SpringBatchTest`. The preceding test
+example can be configured as follows:
+
+```
+@SpringBatchTest
+@RunWith(SpringRunner.class)
+@ContextConfiguration
+public class StepScopeTestExecutionListenerIntegrationTests {
+
+    // This component is defined step-scoped, so it cannot be injected unless
+    // a step is active...
+    @Autowired
+    private ItemReader<String> reader;
+
+    public StepExecution getStepExecution() {
+        StepExecution execution = MetaDataInstanceFactory.createStepExecution();
+        execution.getExecutionContext().putString("input.data", "foo,bar,spam");
+        return execution;
+    }
+
+    @Test
+    public void testReader() {
+        // The reader is initialized and bound to the input data
+        assertNotNull(reader.read());
+    }
+
+}
+```
+
+The listener approach is convenient if you want the duration of the step scope to be the
+execution of the test method. For a more flexible but more invasive approach, you can use
+the `StepScopeTestUtils`. The following example counts the number of items available in
+the reader shown in the previous example:
+
+```
+int count = StepScopeTestUtils.doInStepScope(stepExecution,
+    new Callable<Integer>() {
+      public Integer call() throws Exception {
+
+        int count = 0;
+
+        while (reader.read() != null) {
+           count++;
+        }
+        return count;
+    }
+});
+```
+
+### Validating Output Files
+
+When a batch job writes to the database, it is easy to query the database to verify that
+the output is as expected. However, if the batch job writes to a file, it is equally
+important that the output be verified. Spring Batch provides a class called `AssertFile`to facilitate the verification of output files. The method called `assertFileEquals` takes
+two `File` objects (or two `Resource` objects) and asserts, line by line, that the two
+files have the same content. Therefore, it is possible to create a file with the expected
+output and to compare it to the actual result, as shown in the following example:
+
+```
+private static final String EXPECTED_FILE = "src/main/resources/data/input.txt";
+private static final String OUTPUT_FILE = "target/test-outputs/output.txt";
+
+AssertFile.assertFileEquals(new FileSystemResource(EXPECTED_FILE),
+                            new FileSystemResource(OUTPUT_FILE));
+```
+
+### Mocking Domain Objects
+
+Another common issue encountered while writing unit and integration tests for Spring Batch
+components is how to mock domain objects. A good example is a `StepExecutionListener`, as
+illustrated in the following code snippet:
+
+```
+public class NoWorkFoundStepExecutionListener extends StepExecutionListenerSupport {
+
+    public ExitStatus afterStep(StepExecution stepExecution) {
+        if (stepExecution.getReadCount() == 0) {
+            return ExitStatus.FAILED;
+        }
+        return null;
+    }
+}
+```
+
+The preceding listener example is provided by the framework and checks a `StepExecution`for an empty read count, thus signifying that no work was done. While this example is
+fairly simple, it serves to illustrate the types of problems that may be encountered when
+attempting to unit test classes that implement interfaces requiring Spring Batch domain
+objects. Consider the following unit test for the listener’s in the preceding example:
+
+```
+private NoWorkFoundStepExecutionListener tested = new NoWorkFoundStepExecutionListener();
+
+@Test
+public void noWork() {
+    StepExecution stepExecution = new StepExecution("NoProcessingStep",
+                new JobExecution(new JobInstance(1L, new JobParameters(),
+                                 "NoProcessingJob")));
+
+    stepExecution.setExitStatus(ExitStatus.COMPLETED);
+    stepExecution.setReadCount(0);
+
+    ExitStatus exitStatus = tested.afterStep(stepExecution);
+    assertEquals(ExitStatus.FAILED.getExitCode(), exitStatus.getExitCode());
+}
+```
+
+Because the Spring Batch domain model follows good object-oriented principles, the`StepExecution` requires a `JobExecution`, which requires a `JobInstance` and`JobParameters`, to create a valid `StepExecution`. While this is good in a solid domain
+model, it does make creating stub objects for unit testing verbose. To address this issue,
+the Spring Batch test module includes a factory for creating domain objects:`MetaDataInstanceFactory`. Given this factory, the unit test can be updated to be more
+concise, as shown in the following example:
+
+```
+private NoWorkFoundStepExecutionListener tested = new NoWorkFoundStepExecutionListener();
+
+@Test
+public void testAfterStep() {
+    StepExecution stepExecution = MetaDataInstanceFactory.createStepExecution();
+
+    stepExecution.setExitStatus(ExitStatus.COMPLETED);
+    stepExecution.setReadCount(0);
+
+    ExitStatus exitStatus = tested.afterStep(stepExecution);
+    assertEquals(ExitStatus.FAILED.getExitCode(), exitStatus.getExitCode());
+}
+```
+
+The preceding method for creating a simple `StepExecution` is just one convenience method
+available within the factory. A full method listing can be found in its[Javadoc](https://docs.spring.io/spring-batch/apidocs/org/springframework/batch/test/MetaDataInstanceFactory.html).
\ No newline at end of file

docs/en/spring-web-flow/preface.md

+# Preface
+
+Many web applications require the same sequence of steps to execute in different contexts.
+Often these sequences are merely components of a larger task the user is trying to accomplish.
+Such a reusable sequence is called a flow.
+
+Consider a typical shopping cart application.
+User registration, login, and cart checkout are all examples of flows that can be invoked from several places in this type of application.
+
+Spring Web Flow is the module of Spring for implementing flows.
+The Web Flow engine plugs into the Spring Web MVC platform and provides declarative flow definition language.
+This reference guide shows you how to use and extend Spring Web Flow.