Skip to content

Add flag to show both configuration styles (Java and XML) in reference docs #572

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from
Closed

Add flag to show both configuration styles (Java and XML) in reference docs #572

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
264a202
Made the "Both" option make sense
Jan 30, 2018
8b771b2
Small fixes
Dec 14, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
73 changes: 60 additions & 13 deletions spring-batch-docs/asciidoc/common-patterns.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -50,8 +50,10 @@ public class ItemFailureLoggerListener extends ItemListenerSupport {
}
----

Having implemented this listener, it must be registered with a step, as shown in the
following example:
Having implemented this listener, it must be registered with a step.

[role="xmlContent"]
The following example shows how to register a listener with a step in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -66,6 +68,9 @@ following example:
</step>
----

[role="javaContent"]
The following example shows how to register a listener with a step Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -134,8 +139,10 @@ public class EarlyCompletionItemReader implements ItemReader<T> {
The previous example actually relies on the fact that there is a default implementation
of the `CompletionPolicy` strategy that signals a complete batch when the item to be
processed is `null`. A more sophisticated completion policy could be implemented and
injected into the `Step` through the `SimpleStepFactoryBean`, as shown in the following
example:
injected into the `Step` through the `SimpleStepFactoryBean`.

[role="xmlContent"]
The following example shows how to inject a completion policy into a step in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -150,6 +157,9 @@ example:
<bean id="completionPolicy" class="org.example...SpecialCompletionPolicy"/>
----

[role="javaContent"]
The following example shows how to inject a completion policy into a step in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -196,12 +206,15 @@ so this is always an abnormal ending to a job.
[[addingAFooterRecord]]
=== Adding a Footer Record

Often, when writing to flat files, a "footer" record must be appended to the end of the
Often, when writing to flat files, a "`footer`" record must be appended to the end of the
file, after all processing has be completed. This can be achieved using the
`FlatFileFooterCallback` interface provided by Spring Batch. The `FlatFileFooterCallback`
(and its counterpart, the `FlatFileHeaderCallback`) are optional properties of the
`FlatFileItemWriter` and can be added to an item writer as shown in the following
example:
`FlatFileItemWriter` and can be added to an item writer.

[role="xmlContent"]
The following example shows how to use the `FlatFileHeaderCallback` and the
`FlatFileFooterCallback` in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -214,6 +227,10 @@ example:
</bean>
----

[role="javaContent"]
The following example shows how to use the `FlatFileHeaderCallback` and the
`FlatFileFooterCallback` in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -292,7 +309,10 @@ method, once we are guaranteed that no exceptions are thrown, that we update the

In order for the `writeFooter` method to be called, the `TradeItemWriter` (which
implements `FlatFileFooterCallback`) must be wired into the `FlatFileItemWriter` as the
`footerCallback`. The following example shows how to do so:
`footerCallback`.

[role="xmlContent"]
The following example shows how to wire the `TradeItemWriter` in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -308,6 +328,9 @@ implements `FlatFileFooterCallback`) must be wired into the `FlatFileItemWriter`
</bean>
----

[role="javaContent"]
The following example shows how to wire the `TradeItemWriter` in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -409,7 +432,10 @@ multi-line record as a group, so that it can be passed to the `ItemWriter` intac
Because a single record spans multiple lines and because we may not know how many lines
there are, the `ItemReader` must be careful to always read an entire record. In order to
do this, a custom `ItemReader` should be implemented as a wrapper for the
`FlatFileItemReader`, as shown in the following example:
`FlatFileItemReader`.

[role="xmlContent"]
The following example shows how to implement a custom `ItemReader` in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -429,6 +455,9 @@ do this, a custom `ItemReader` should be implemented as a wrapper for the
</bean>
----

[role="javaContent"]
The following example shows how to implement a custom `ItemReader` in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -459,7 +488,10 @@ delegate `FlatFileItemReader`. See
link:readersAndWriters.html#flatFileItemReader[`FlatFileItemReader` in the Readers and
Writers chapter] for more details. The delegate reader then uses a
`PassThroughFieldSetMapper` to deliver a `FieldSet` for each line back to the wrapping
`ItemReader`, as shown in the following example:
`ItemReader`.

[role="xmlContent"]
The following example shows how to ensure that each line is properly tokenized in XML:

.XML Content
[source, xml, role="xmlContent"]
Expand All @@ -476,6 +508,9 @@ Writers chapter] for more details. The delegate reader then uses a
</bean>
----

[role="javaContent"]
The following example shows how to ensure that each line is properly tokenized in Java:

.Java Content
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -545,7 +580,10 @@ common metadata about the run would be lost. Furthermore, a multi-step job would
need to be split up into multiple jobs as well.

Because the need is so common, Spring Batch provides a `Tasklet` implementation for
calling system commands, as shown in the following example:
calling system commands.

[role="xmlContent"]
The following example shows how to call an external command in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand All @@ -557,6 +595,9 @@ calling system commands, as shown in the following example:
</bean>
----

[role="javaContent"]
The following example shows how to call an external command in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down Expand Up @@ -639,13 +680,16 @@ public class SavingItemWriter implements ItemWriter<Object> {
}
----

To make the data available to future `Steps`, it must be "promoted" to the `Job`
To make the data available to future `Steps`, it must be "`promoted`" to the `Job`
`ExecutionContext` after the step has finished. Spring Batch provides the
`ExecutionContextPromotionListener` for this purpose. The listener must be configured
with the keys related to the data in the `ExecutionContext` that must be promoted. It can
also, optionally, be configured with a list of exit code patterns for which the promotion
should occur (`COMPLETED` is the default). As with all listeners, it must be registered
on the `Step` as shown in the following example:
on the `Step`.

[role="xmlContent"]
The following example shows how to promote a step to the `Job` `ExecutionContext` in XML:

.XML Configuration
[source, xml, role="xmlContent"]
Expand Down Expand Up @@ -674,6 +718,9 @@ on the `Step` as shown in the following example:
</beans:bean>
----

[role="xmlContent"]
The following example shows how to promote a step to the `Job` `ExecutionContext` in Java:

.Java Configuration
[source, java, role="javaContent"]
----
Expand Down
30 changes: 16 additions & 14 deletions spring-batch-docs/asciidoc/domain.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -63,10 +63,11 @@ global to all steps, such as restartability. The job configuration contains:

ifdef::backend-html5[]
[role="javaContent"]
A default simple implementation of the Job interface is provided by Spring Batch 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 example:
For those who use Java configuration, Spring Batch provices 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
example:

[source, java, role="javaContent"]
----
Expand All @@ -82,10 +83,11 @@ public Job footballJob() {
----

[role="xmlContent"]
A default simple implementation of the `Job` interface is provided by Spring Batch in the
form of the `SimpleJob` class, which creates some standard functionality on top of `Job`.
However, the batch namespace abstracts away the need to instantiate it directly. Instead,
the `<job>` tag can be used as shown in the following example:
For those who use XML 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`. However, the batch namespace abstracts away the need to
instantiate it directly. Instead, the `<job>` element can be used, as shown in the
following example:

[source, xml, role="xmlContent"]
----
Expand All @@ -98,9 +100,9 @@ the `<job>` tag can be used as shown in the following example:
endif::backend-html5[]

ifdef::backend-pdf[]
A default simple implementation of the Job interface is provided by Spring Batch 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 are made available for the
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 are made available for the
instantiation of a `Job`, as shown in the following example:

[source, java]
Expand Down Expand Up @@ -565,16 +567,16 @@ the course of execution, `StepExecution` and `JobExecution` implementations are
by passing them to the repository.

[role="xmlContent"]
The batch namespace provides support for configuring a `JobRepository` instance with the
`<job-repository>` tag, as shown in the following example:
The Spring Batch XML namespace provides support for configuring a `JobRepository` instance
with the `<job-repository>` tag, as shown in the following example:

[source, xml, role="xmlContent"]
----
<job-repository id="jobRepository"/>
----

[role="javaContent"]
When using java configuration, `@EnableBatchProcessing` annotation provides a
When using Java configuration, the `@EnableBatchProcessing` annotation provides a
`JobRepository` as one of the components automatically configured out of the box.

=== JobLauncher
Expand Down
Loading