From f6f01b5bb1bbfb4f34a6f7a1ef4119533492ea76 Mon Sep 17 00:00:00 2001 From: Glenn Renfro Date: Thu, 20 Jul 2017 17:52:31 -0400 Subject: [PATCH] Corrected errors in docs and removed index-pdf.adoc index-pdf.adoc was a duplicate of index-single.adoc. And thus was not necessary The errors corrected were identified in https://github.com/spring-projects/spring-batch/pull/429 Resolves BATCH-2632 --- spring-batch-docs/asciidoc/index-pdf.adoc | 39 --------------------- spring-batch-docs/asciidoc/repeat.adoc | 16 ++++----- spring-batch-docs/asciidoc/retry.adoc | 2 +- spring-batch-docs/asciidoc/scalability.adoc | 4 +-- 4 files changed, 11 insertions(+), 50 deletions(-) delete mode 100644 spring-batch-docs/asciidoc/index-pdf.adoc diff --git a/spring-batch-docs/asciidoc/index-pdf.adoc b/spring-batch-docs/asciidoc/index-pdf.adoc deleted file mode 100644 index 8cc69698d..000000000 --- a/spring-batch-docs/asciidoc/index-pdf.adoc +++ /dev/null @@ -1,39 +0,0 @@ -:doctype: book -:toc: -:toclevels: 4 - -include::header/index-header.adoc[] - -include::spring-batch-intro.adoc[] - -include::whatsnew.adoc[] - -include::domain.adoc[] - -include::job.adoc[] - -include::step.adoc[] - -include::readersAndWriters.adoc[] - -include::scalability.adoc[] - -include::repeat.adoc[] - -include::retry.adoc[] - -include::testing.adoc[] - -include::common-patterns.adoc[] - -include::jsr-352.adoc[] - -include::spring-batch-integration.adoc[] - -include::appendix.adoc[] - -include::schema-appendix.adoc[] - -include::transaction-appendix.adoc[] - -include::glossary.adoc[] \ No newline at end of file diff --git a/spring-batch-docs/asciidoc/repeat.adoc b/spring-batch-docs/asciidoc/repeat.adoc index 8183b9a21..539b1e488 100644 --- a/spring-batch-docs/asciidoc/repeat.adoc +++ b/spring-batch-docs/asciidoc/repeat.adoc @@ -63,13 +63,13 @@ The simplest general purpose implementation of ---- RepeatTemplate template = new RepeatTemplate(); -template.setCompletionPolicy(new FixedChunkSizeCompletionPolicy(2)); +template.setCompletionPolicy(new SimpleCompletionPolicy(2)); template.iterate(new RepeatCallback() { - public ExitStatus doInIteration(RepeatContext context) { + public RepeatStatus doInIteration(RepeatContext context) { // Do stuff in batch... - return ExitStatus.CONTINUABLE; + return RepeatStatus.CONTINUABLE; } }); @@ -77,7 +77,7 @@ template.iterate(new RepeatCallback() { In the example we return `RepeatStatus.CONTINUABLE` to show that there is more work to do. The callback can also return - `ExitStatus.FINISHED` if it wants to signal to the caller that + `RepeatStatus.FINISHED` if it wants 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 @@ -112,7 +112,7 @@ A `RepeatContext` will have a parent context Spring Batch to indicate whether processing has finished. These are possible `RepeatStatus` values: -.ExitStatus Properties +.RepeatStatus Properties |=============== |__Value__|__Description__ @@ -295,12 +295,12 @@ The example above uses a default `RepeatTemplate` into the interceptor. If the intercepted method returns `void` then the - interceptor always returns `ExitStatus.CONTINUABLE` (so there is a danger of + 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 - `ExitStatus.CONTINUABLE` until the return value from the + `RepeatStatus.CONTINUABLE` until the return value from the intercepted method is null, at which point it returns - `ExitStatus.FINISHED`. So the business logic inside the target + `RepeatStatus.FINISHED`. So 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 diff --git a/spring-batch-docs/asciidoc/retry.adoc b/spring-batch-docs/asciidoc/retry.adoc index 06068b458..57560994e 100644 --- a/spring-batch-docs/asciidoc/retry.adoc +++ b/spring-batch-docs/asciidoc/retry.adoc @@ -24,7 +24,7 @@ To make processing more robust and less prone to failure, sometimes succeed on a subsequent attempt. Errors that are susceptible to this kind of treatment are transient in nature. For example a remote call to a web service or RMI service that fails because of a network glitch or a - `DeadLockLoserException` in a database update may + `DeadlockLoserDataAccessException` in a database update may resolve themselves after a short wait. To automate the retry of such operations Spring Batch has the `RetryOperations` strategy. The `RetryOperations` interface looks like diff --git a/spring-batch-docs/asciidoc/scalability.adoc b/spring-batch-docs/asciidoc/scalability.adoc index cdad620be..8f987c6b6 100644 --- a/spring-batch-docs/asciidoc/scalability.adoc +++ b/spring-batch-docs/asciidoc/scalability.adoc @@ -352,13 +352,13 @@ The names of the step executions (the keys in the this convention. An optional interface - `PartitioneNameProvider` can be used to + `PartitionNameProvider` can be used to provide the partition names separately from the partitions themselves. If a Partitioner implements this interface then on a restart only the names will be queried. If partitioning is expensive this can be a useful optimisation. Obviously the names provided by the - `PartitioneNameProvider` must match those + `PartitionNameProvider` must match those provided by the `Partitioner`. [[bindingInputDataToSteps]]