Fix typos in documentation

spring-batch-docs/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

spring-batch-docs/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.

spring-batch-docs/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"]

spring-batch-docs/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

spring-batch-docs/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

spring-batch-docs/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