2
2
:toc: left
3
3
:toclevels: 4
4
4
5
- [[processor ]]
6
- == ItemProcessor
5
+ [[itemProcessor ]]
6
+ == Item processing
7
7
8
8
ifndef::onlyonetoggle[]
9
9
include::toggle.adoc[]
10
10
endif::onlyonetoggle[]
11
11
12
- The ` ItemReader` and ` ItemWriter` interfaces are both very useful for their specific
12
+ The <<readersAndWriters.adoc#readersAndWriters, ItemReader and ItemWriter interfaces>> are both very useful for their specific
13
13
tasks, but what if you want to insert business logic before writing? One option for both
14
14
reading and writing is to use the composite pattern: Create an `ItemWriter` that contains
15
15
another `ItemWriter` or an `ItemReader` that contains another `ItemReader`. The following
@@ -117,7 +117,7 @@ public Job ioSampleJob() {
117
117
@Bean
118
118
public Step step1() {
119
119
return this.stepBuilderFactory.get("step1")
120
- .<String, String >chunk(2)
120
+ .<Foo, Bar >chunk(2)
121
121
.reader(fooReader())
122
122
.processor(fooProcessor())
123
123
.writer(barWriter())
@@ -129,7 +129,7 @@ A difference between `ItemProcessor` and `ItemReader` or `ItemWriter` is that an
129
129
is optional for a `Step`.
130
130
131
131
[[chainingItemProcessors]]
132
- ==== Chaining ItemProcessors
132
+ === Chaining ItemProcessors
133
133
134
134
Performing a single transformation is useful in many scenarios, but what if you want to
135
135
'chain' together multiple `ItemProcessor` implementations? This can be accomplished using
@@ -223,7 +223,7 @@ public Job ioSampleJob() {
223
223
@Bean
224
224
public Step step1() {
225
225
return this.stepBuilderFactory.get("step1")
226
- .<String, String >chunk(2)
226
+ .<Foo, Foobar >chunk(2)
227
227
.reader(fooReader())
228
228
.processor(compositeProcessor())
229
229
.writer(foobarWriter())
@@ -245,7 +245,7 @@ public CompositeItemProcessor compositeProcessor() {
245
245
----
246
246
247
247
[[filteringRecords]]
248
- ==== Filtering Records
248
+ === Filtering Records
249
249
250
250
One typical use for an item processor is to filter out records before they are passed to
251
251
the `ItemWriter`. Filtering is an action distinct from skipping. Skipping indicates that
@@ -265,7 +265,7 @@ the `ItemWriter`. As usual, an exception thrown from the `ItemProcessor` results
265
265
skip.
266
266
267
267
[[validatingInput]]
268
- ==== Validating Input
268
+ === Validating Input
269
269
270
270
In the <<readersAndWriters.adoc#readersAndWriters,ItemReaders and ItemWriters>> chapter, multiple approaches to parsing input have been
271
271
discussed. Each major implementation throws an exception if it is not 'well-formed'. The
@@ -369,7 +369,7 @@ public BeanValidatingItemProcessor<Person> beanValidatingItemProcessor() throws
369
369
----
370
370
371
371
[[faultTolerant]]
372
- ==== Fault Tolerance
372
+ === Fault Tolerance
373
373
374
374
When a chunk is rolled back, items that have been cached during reading may be
375
375
reprocessed. If a step is configured to be fault tolerant (typically by using skip or
0 commit comments