Skip to content

Commit 875be70

Browse files
rohitsanjfmbenhassine
authored andcommitted
Fix typos in documentation
1 parent abcd960 commit 875be70

File tree

6 files changed

+7
-7
lines changed

6 files changed

+7
-7
lines changed

spring-batch-docs/src/main/asciidoc/domain.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -63,7 +63,7 @@ global to all steps, such as restartability. The job configuration contains:
6363

6464
ifdef::backend-html5[]
6565
[role="javaContent"]
66-
For those who use Java configuration, Spring Batch provices a default implementation of
66+
For those who use Java configuration, Spring Batch provides a default implementation of
6767
the Job interface in the form of the `SimpleJob` class, which creates some standard
6868
functionality on top of `Job`. When using java based configuration, a collection of
6969
builders is made available for the instantiation of a `Job`, as shown in the following

spring-batch-docs/src/main/asciidoc/glossary.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ Item::
5252
terms, this might be a line in a file, a row in a database table, or a particular
5353
element in an XML file.
5454

55-
Logicial Unit of Work (LUW)::
55+
Logical Unit of Work (LUW)::
5656
A batch job iterates through a driving query (or other input source, such as a file) to
5757
perform the set of work that the job must accomplish. Each iteration of work performed
5858
is a unit of work.

spring-batch-docs/src/main/asciidoc/readersAndWriters.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1694,7 +1694,7 @@ file-1.txt file-2.txt ignored.txt
16941694
----
16951695

16961696
file-1.txt and file-2.txt are formatted the same and, for business reasons, should be
1697-
processed together. The `MuliResourceItemReader` can be used to read in both files by
1697+
processed together. The `MultiResourceItemReader` can be used to read in both files by
16981698
using wildcards.
16991699

17001700
[role="xmlContent"]

spring-batch-docs/src/main/asciidoc/scalability.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -245,7 +245,7 @@ expensive than the reading of items (as is often the case in practice).
245245
The manager is an implementation of a Spring Batch `Step` with the `ItemWriter` replaced
246246
by a generic version that knows how to send chunks of items to the middleware as
247247
messages. The workers are standard listeners for whatever middleware is being used (for
248-
example, with JMS, they would be `MesssageListener` implementations), and their role is
248+
example, with JMS, they would be `MessageListener` implementations), and their role is
249249
to process the chunks of items using a standard `ItemWriter` or `ItemProcessor` plus
250250
`ItemWriter`, through the `ChunkProcessor` interface. One of the advantages of using this
251251
pattern is that the reader, processor, and writer components are off-the-shelf (the same

spring-batch-docs/src/main/asciidoc/step.adoc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2079,7 +2079,7 @@ elsewhere in XML:
20792079
The following example shows how to declare a flow as a reference to a flow defined
20802080
elsewhere in Java:
20812081

2082-
.Java Confguration
2082+
.Java Configuration
20832083
[source, java, role="javaContent"]
20842084
----
20852085
@Bean

spring-batch-docs/src/main/asciidoc/transaction-appendix.adoc

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -108,7 +108,7 @@ alternate paths for processing: the normal case, as denoted by `PROCESS` (5), an
108108
recovery path, as denoted in a separate block by `RECOVER` (6). The two alternate paths
109109
are completely distinct. Only one is ever taken in normal circumstances.
110110

111-
In special cases (such as a special `TranscationValidException` type), the retry policy
111+
In special cases (such as a special `TransactionValidException` type), the retry policy
112112
might be able to determine that the `RECOVER` (6) path can be taken on the last attempt
113113
after `PROCESS` (5) has just failed, instead of waiting for the item to be re-presented.
114114
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.
267267
Consequently, the `NESTED` pattern is best if the retry block contains any database
268268
access.
269269

270-
[[specialTransactionOrthonogonal]]
270+
[[specialTransactionOrthogonal]]
271271
=== Special Case: Transactions with Orthogonal Resources
272272

273273
Default propagation is always OK for simple cases where there are no nested database

0 commit comments

Comments
 (0)