This commit replaces the usage of List with Chunk
where appropriate. Summary of changes:
- The Chunk class was moved from the `org.springframework.batch.core.step.item` package to the `org.springframework.batch.item` package
- The signature of the method `ItemWriter#write(List)` was changed to `ItemWriter#write(Chunk)`
- All implementations of `ItemWriter` were updated to use the Chunk API instead of List
- All methods in the `ItemWriteListener` interface were updated to use the Chunk API instead of List
- All implementations of `ItemWriteListener` were updated to use the Chunk API instead of List
- The constructor of `ChunkRequest` was changed to accept a Chunk instead of a Collection of items
- The return type of `ChunkRequest#getItems()` was changed from List to Chunk
Resolves#3954
Guarded the logging statements which do concatenation of strings
or calling toString on objects. When a log level isn't enabled
this still would produce garbage that would need to be collected.
Guarded all logging up to info, warn and error can be assumed to be
enabled on a production system.
This commit changes the remote chunking and partitioning master step
builders to either accept an output channel or a messaging template
but not both.
See BATCH-2687
Without a default constructor, a StepExecutionRequest instance cannot
be deserialized using Jackson. This commit adds a (private) default
constructor to fix the issue.
Resolves BATCH-2732
This commit adds a new annotation `@EnableBatchIntegration` that makes
it possible to autowire two beans in the application context:
* RemoteChunkingMasterStepBuilderFactory: used to create a master step
* RemoteChunkingWorkerBuilder: used to create a worker integration flow
The goal of these new APIs is to simplify the setup of remote chunking
job by automatically configuring infrastructure beans.
Resolves BATCH-2686
When using the `AsyncItemProcessor` and `AsyncItemWriter`, business
exceptions that occur during the process phase are hidden by an
`ExecutionException` that is returned wrapping the originally thrown
exception in the `AsyncItemWriter`. In this commit, we now unwrap any
`ExecutionException` that is returned and throw the cause. Debug
logging is also added to allow the logging of the original exception as
well.
Resolves BATCH-2386
When using the `MessageChannelPartitionHandler`, the reply channel is an
instance variable. However, when the handle method is called, if a
reply channel is not injected, it will create a new one. If multiple
jobs recycle the same instance of the partition handler, you may end up
having messages crossed/lost. This PR removes the creation of the reply
channel for each call to the handle method and documents that this
comonent should be step scoped.
Resolves BATCH-2288
The new Spring 5 baseline consists of Spring 5, Hibernate 5, and Java 8.
This commit addresses any changes to create a successful build of Spring
Batch under those guidances. Further commits will be coming to address
Java 8 specifics as areas of the project are touched.
Resolves BATCH-2536
In various places in the code base a debug message is constructed
unconditionally. This adds unnecessary overhead in the common case when
debug logging is off.
- add guards around debug statements in non-test code
Issue: BATCH-2412
This commit adds the feature of allowing a delegate ItemWriter to be an
ItemStreamWriter and have Spring Batch respect the ItemStream lifecycle
events without explicitly configuring the delegate as a stream.
When using remote partitioning, each slave worker persists it's current
status in the same job repsository that the master uses. Because of
this, there is no hard need for the master to wait for each worker to
send a formal response once it's work is complete. Instead, the master
(at the cost of polling a db periodically) can determine if the workers
are done by looking up each partition's status in the job repository.
This commit removes the requirement for a reply channel and implements
the polling of the job repository to determine if the workers are done.
BATCH-2332
The AsyncItemWriter is used in conjunction with the AsyncItemProcessor
to unwrap the Futures that are returned by that processor.
Traditionally when an ItemProcessor returns null, it's considered having
been filtered out and should not be passed to the ItemWriter. In this
case, the AsyncItemWriter was not checking for nulls so they were being
passed to the delegate ItemWriter. Most of the OOTB ItemWriters do not
perform a null check prior to doing the write so they were throwing NPEs
when using this paradigm.
