setCommand now supports passing in an array of strings. When a single
string is supplied, it is tokenized by the Runtime#exec method. When an
array of strings is supplied, the array is supplied as is to the
Runtime#exec method in which case no tokenization takes place.
Resolves#752
Persisting a LocalDateTime as a Timestamp with `Timestamp.valueOf(LocalDateTime)`
and retrieving it with `ResultSet#getObject(index, LocalDateTime.class)` seems
to result in a data loss at the millisecond fraction level.
This commit changes the usage of `ResultSet#getObject(index, LocalDateTime.class)`
to `ResultSet#getTimestamp(index).toLocalDateTime()`.
A round trip to the database with `Timestamp.valueOf(LocalDateTime)` and
`Timestamp.toLocalDateTime()` should not result in a data loss.
This commit changes the type of fields `startTime`, `endTime`,
`createTime` and `lastUpdated` in `JobExecution` and `StepExecution`
from `java.util.Date` to `java.time.LocalDateTime`.
Resolves#1014
This commit changes the default execution context serializer to
DefaultExecutionContextSerializer, which makes Jackson an optional
dependency.
Resolves#4140
The support to use any type as a job parameter was added
in #3960.
This commit introduces convenience methods where appropriate
to use Java 8 Date/Time APIs as job parameters.
Resolves#1035
Before this commit, the transaction attributes were hardcoded and not
configurable in the proxy created by Job explorer/repository/operator
factory beans.
This commit adds the possibility to customize the transaction attributes
in addition to the transaction manager. It is now possible to configure
the transaction's isolation level as well as its propagation for each
method if needed.
Resolves#4195
This commit adds support to configure and create a transactional
proxy around SimpleJobOperator through a factory bean.
The usage of `@Transactional` was removed in favor of
the programmatic way of customizing the proxy through
the factory bean.
Resolves#1078
Before this commit, the configuration of infrastructure beans
was confusing and not straightforward to customize. This commit
changes the way Batch infrastructure beans are configured.
The most important changes are:
* EnableBatchProcessing now provides new attributes to
configure properties of infrastructure beans
* Bean registration is now done programmatically with a
BeanDefinitionRegistrar instead of importing a class with
statically annotated bean definition methods
* Bean are now resolved from the application context directly
instead of being resolved from a BatchConfigurer
* Both a data source and a transaction manager are now
required to be defined in the application context
* A new configuration class called DefaultBatchConfiguration
with default infrastructure bean definitions is now provided
and can be extended to customize the default configuration
Resolves#3942
Before this commit, the user had to manually set the job repository and transaction
manager on `JobBuilder` and `StepBuilder` instances with a chained call to
`.repository(jobRepository)` and `.transactionManager(transactionManager)`.
This is error prone and can lead to runtime errors if these properties are not set.
This commit introduces new APIs to guide the user to set these properties at
builder creation time.
Resolves#4192
Before this commit, the transaction manager was configurable
by implementing `BatchConfigurer#getTransactionManager`.
The transaction manager being an implementation detail of the
`JobRepository`, it should not be configurable at the same level
as the `JobRepository` (ie in the same interface).
This commit removes the method `getTransactionManager` from
the `BatchConfigurer` interface. If needed, a custom transaction
manager could be supplied by implementing `getJobRepository`,
or via the constructor of `DefaultBatchConfigurer`.
Resolves https://github.com/spring-projects/spring-batch/issues/4191
This commit deprecates JobBuilderFactory and StepBuilderFactory
in favor of the respective builders they create.
It also removes the exposure of such utilities as beans in the
application context when using `@EnableBatchProcessing`.
Resolves https://github.com/spring-projects/spring-batch/issues/4188
Before this commit, the transaction manager was configurable
at the StepBuilder level, which is inconsistent with the XML
config style in addition to be not needed for most step types.
This commit moves the configuration of the transaction manager
from the StepBuilder down to the AbstractTaskletStepBuilder,
which is the level where the transaction manager is needed.
Resolves#4130
This reverts commit bf2e6ab0e5
as the change was made after spring-framework 6.0.0-M5 was
released. This version is required to release spring-batch
5.0.0-M5
This change will be put back after releasing 5.0.0-M5.
Before this commit, the `JobRepositoryTestUtils` was
tied to the JDBC implementation of the `JobRepository`
as it was requiring a datasource. This makes it unusable
with implementations that do not rely on a datasource
to store batch meta-data (A MongoDB job repository for
instance where no datasource is used).
This commit decouples the `JobRepositoryTestUtils` from
the implementation details of the `JobRepository` by making
it working against the `JobRepository` interface.
This commit also introduces the necessary methods in the
`JobRepository` interface as well as various DAOs to
implement the utilities without having to deal with the
details of the underlying repository implementation.
Resolves#4070
The documentation generation change introduced
in #4167 seems to scan more files than previously
WRT checking the code formatting style.
This commit fixes the formatting of the files
that do not conform to the Spring style.
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
