diff --git a/spring-batch-docs/src/main/asciidoc/domain.adoc b/spring-batch-docs/src/main/asciidoc/domain.adoc index 4dbb9b7c7b..cd4a10fd46 100644 --- a/spring-batch-docs/src/main/asciidoc/domain.adoc +++ b/spring-batch-docs/src/main/asciidoc/domain.adoc @@ -63,7 +63,7 @@ global to all steps, such as restartability. The job configuration contains: ifdef::backend-html5[] [role="javaContent"] -For those who use Java configuration, Spring Batch provices a default implementation of +For those who use Java configuration, Spring Batch provides a default implementation of the Job interface in the form of the `SimpleJob` class, which creates some standard functionality on top of `Job`. When using java based configuration, a collection of builders is made available for the instantiation of a `Job`, as shown in the following diff --git a/spring-batch-docs/src/main/asciidoc/glossary.adoc b/spring-batch-docs/src/main/asciidoc/glossary.adoc index 98b9fc25e5..04822a345d 100644 --- a/spring-batch-docs/src/main/asciidoc/glossary.adoc +++ b/spring-batch-docs/src/main/asciidoc/glossary.adoc @@ -52,7 +52,7 @@ Item:: terms, this might be a line in a file, a row in a database table, or a particular element in an XML file. -Logicial Unit of Work (LUW):: +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. diff --git a/spring-batch-docs/src/main/asciidoc/readersAndWriters.adoc b/spring-batch-docs/src/main/asciidoc/readersAndWriters.adoc index 1eee0f5c53..1f3b4f4aef 100644 --- a/spring-batch-docs/src/main/asciidoc/readersAndWriters.adoc +++ b/spring-batch-docs/src/main/asciidoc/readersAndWriters.adoc @@ -1694,7 +1694,7 @@ file-1.txt file-2.txt ignored.txt ---- file-1.txt and file-2.txt are formatted the same and, for business reasons, should be -processed together. The `MuliResourceItemReader` can be used to read in both files by +processed together. The `MultiResourceItemReader` can be used to read in both files by using wildcards. [role="xmlContent"] diff --git a/spring-batch-docs/src/main/asciidoc/scalability.adoc b/spring-batch-docs/src/main/asciidoc/scalability.adoc index a598c96cab..b6c20b1067 100644 --- a/spring-batch-docs/src/main/asciidoc/scalability.adoc +++ b/spring-batch-docs/src/main/asciidoc/scalability.adoc @@ -245,7 +245,7 @@ expensive than the reading of items (as is often the case in practice). The manager is an implementation of a Spring Batch `Step` with the `ItemWriter` replaced by a generic version that knows how to send chunks of items to the middleware as messages. The workers are standard listeners for whatever middleware is being used (for -example, with JMS, they would be `MesssageListener` implementations), and their role is +example, with JMS, they would be `MessageListener` implementations), and their role is to process the chunks of items using a standard `ItemWriter` or `ItemProcessor` plus `ItemWriter`, through the `ChunkProcessor` interface. One of the advantages of using this pattern is that the reader, processor, and writer components are off-the-shelf (the same diff --git a/spring-batch-docs/src/main/asciidoc/step.adoc b/spring-batch-docs/src/main/asciidoc/step.adoc index e654cac63a..093ef74be6 100644 --- a/spring-batch-docs/src/main/asciidoc/step.adoc +++ b/spring-batch-docs/src/main/asciidoc/step.adoc @@ -2079,7 +2079,7 @@ elsewhere in XML: The following example shows how to declare a flow as a reference to a flow defined elsewhere in Java: -.Java Confguration +.Java Configuration [source, java, role="javaContent"] ---- @Bean diff --git a/spring-batch-docs/src/main/asciidoc/transaction-appendix.adoc b/spring-batch-docs/src/main/asciidoc/transaction-appendix.adoc index db61583bd1..f4e68ae8a6 100644 --- a/spring-batch-docs/src/main/asciidoc/transaction-appendix.adoc +++ b/spring-batch-docs/src/main/asciidoc/transaction-appendix.adoc @@ -108,7 +108,7 @@ alternate paths for processing: the normal case, as denoted by `PROCESS` (5), an recovery path, as denoted in a separate block by `RECOVER` (6). The two alternate paths are completely distinct. Only one is ever taken in normal circumstances. -In special cases (such as a special `TranscationValidException` type), the retry policy +In special cases (such as a special `TransactionValidException` type), the retry policy might be able to determine that the `RECOVER` (6) path can be taken on the last attempt after `PROCESS` (5) has just failed, instead of waiting for the item to be re-presented. This is not the default behavior, because it requires detailed knowledge of what has @@ -267,7 +267,7 @@ JTA, but it is the only one that consistently works. Consequently, the `NESTED` pattern is best if the retry block contains any database access. -[[specialTransactionOrthonogonal]] +[[specialTransactionOrthogonal]] === Special Case: Transactions with Orthogonal Resources Default propagation is always OK for simple cases where there are no nested database