Before this commit, the AutomaticJobRegistrar was started on
ContextRefreshedEvent event. This is sometimes too late to register jobs
especially when other life cycle components that use the jobs are started
before this registrar.
This commit changes the AutomaticJobRegistrar to implement SmartLifeCycle
and makes its autoStartup and phase properties configurable.
It should be noted that the "onApplicationEvent" method has been removed
even if it is a public API. This method is not intended to be used by
client code and even if it was, its usage is considered wrong anyway.
Resolves BATCH-2564
Before this commit, options passed on the command line were collected
in a HashSet. This does not keep options order as they are passed in
the command line.
This commit changes the "opts" variable type to LinkedHashSet.
Note there is no test for this change as "opts" is a local variable to
the main method.
Resolves BATCH-2491
Before this commit, annotation based chunk listeners were not registered
when using a non-fault tolerant step builder.
This commit moves the code of chunk listener annotations handling to the
AbstractTaskletStepBuilder so that other tasklet builders can use it.
Resolves BATCH-2445
Before this commit, the JsrPartitionHandler was polling partitions
completion continuously. This causes a high CPU usage.
This commit makes the polling thread sleep for a configurable amount
of time in order to decrease CPU usage during the polling period.
Resolves BATCH-2401
Currently, the Jackson2ExecutionContextStringSerializer fails to
deserialize json representations of:
* empty JobParameters instances due to the presence of "empty":true
in the serialized json String. In this case, Jackson is not able to find a
property named "empty" in the target type (JobParameters)
* JobParameter instances due to the presence of several constructors.
In this case, Jackson does not know which constructor to use.
This commit fixes these two issues by adding a custom Jackson module with:
* a mixin to ignore the "isEmpty" getter in JobParameters type
* a custom deserializer for JobParameter type
Resolves BATCH-2680
Currently, when multiple data sources are defined in the context, an
IllegalStateException is thrown even if one of the data sources is
annotated with @Primary (which should be the one to use).
This commit makes it possible to use the data source annotated with
@Primary when multiple data sources are defined. Note that the context
initialization will still fail (with a UnsatisfiedDependencyException
from Spring's bean factory) if multiple data sources are defined and
none of them is annotated with @Primary. If multiple data sources are
defined and none of them is annotated with @Primary but one of them is
named "dataSource", this data source will be used by the batch
configuration due to autowiring by name (this detail has been documented
in the javadoc of @EnableBatchProcessing).
Resolves BATCH-2537
When a tasklet is declared with xml using the shortcut version, the
MethodInvokingTaskletAdapter that is created automatically does not
address passing parameters expected by Tasklet#execute (which is
incorrect since the documentation of the schema attribute "method"
says the bean should define a method with the same signature).
This commit fixes parameters passing when using the shortcut version.
Resolves BATCH-2397
Before this commit, the filter count of the contribution was applied
for each item of a scanned chunk. For example, with a chunk of 30,
if the filter count is 10 and an item is skipped during write, then the
filter count is equal to 210 (10 + 20 * 10).
If this commit is applied, the filter count will be re-initialized when
scanning the chunk.
Resolves BATCH-2663
Before this commit, when a job execution is stopped from a different
JVM than the one running the job, a warning says that the job cannot
be found. This was confusing to some users since the job can be found
in the database (but is actually not defined in the job registry of
the application context of the second JVM).
After this commit is applied, the warning will be more explicit to
inform the user that the job cannot be found in the job registry
(to not be confused with the database)
Resolves BATCH-2667
In order to make the Map based JobRepository threadsafe, the
JobExecutino was modified to use a `CopyOnWriteArraySet` for the
collection backing the child `StepExecution` collection. However, this
collection option has bad performance characteristics when used with
large collections. When using partitioning, it can be common to have a
large number of `StepExecution` instances to add which drastically hurts
start up time.
This commit remove the use of the `CopyOnWriteArraySet` for the
`JobExecution#stepExecutions` and replaces it with a `LinkedHashSet`
wrapped via `Collection.synchronizedSet`.
Resolves BATCH-2384
Why:
Listeners should be called in normal order before some event
(i.e. read, write) and after that event in reverse order.
Side effects:
The ordering of Chunk and ItemReader Listeners is changed and will
change some behaviors of users. This change is still neccesary because
it is not only the correct and obviouse way, but also prevents new
users to hack around this problem.
In a previous commit, the JobParametersBuilder was updated to include
some code from Spring Boot that handled the incrementing of
JobParameters for a previous job. That commit brought over a private
`merge` method that is actually useful for general consumption.
This commit adds a `addJobParameters` method to the builder providing
the same functionality the `merge` method did in a public method.
This commit adds a new `ItemProcessor` that delegates to a
`java.util.function.Function`. It also enables users to configure a
`Function` as an `ItemProcessor` via the builders (so they don't need to
worry about the `ItemProcessor` wrapper in the first place).
Resolves BATCH-2641
The current default for serializing the ExecutionContext is via XStream
using Jettison's driver. However, recent updates to Jettison make it
incompatible with XStream with no progress on a fix. Because of this,
and to encourage the use of well supported library combinations, the
default ExecutionContext serialization mechanism for Spring Batch has
been switched to Jackson (via the
Jackson2ExecutionContextStringSerializer). This commit also depricates
the XStreamExecutionContextStringSerializer for removal at a later date.
However, it is still available for users that require that during a
migration.
Resolves BATCH-2575
Spring Batch's implementation of JSR-352 previously relied on Spring's
ContextSingletonBeanFactoryLocator. However, this has been removed in
Spring 5 as a relic of older EJB based use cases. This commit now
lazily bootstraps the base context on it's own when the first
JsrJobOperator is requested.
Resolves BATCH-2572
The exception message for the Serializable check in
DefaultExecutionContextSerializer is always generated. For large
contexts this can quickly put a log of pressure on the allocator and
the heap.
This commit contains the following changes:
* generate the exception message for non-serializable values in
DefaultExecutionContextSerializer only when needed
I have signed and agree to the terms of the SpringSource Individual
Contributor License Agreement.
Issue: BATCH-2396
This commit moves all SNAPSHOT dependencies to the latest available
released versions. It also addresses a number of deprications in the
Spring Data realm. Specifically around the deprication of the
Neo4JOperations and the package reorganization within Hibernate.
When determining if an exception should be skipped or not, the business
exception should be used. However, when an exception is thrown in the
listener, it's wrapped by a `StepListenerFailedException`. This leads
to it hiding the underlying exception. This commit will unwrap the
cause of a `StepListenerFailedException` and use that to determine if it
should be skipped or not.
Resolves BATCH-2322
Prior to this commit, when using the `JobStep`, if the child job was
stopped (left in the `STOPPED` state), the step executing that job was
marked as `COMPLETE`, preventing it from being restarted. This commit
now marks a step that was executing the stopped job also as stopped,
allowing for it to be restarted.
Resolves BATCH-2429
Previously, AutomaticJobRegistrar listened to all ApplicationEvents
despite only being interested in two ApplicationContextEvents, namely
ContextRefreshedEvent and ContextClosedEvent. This could lead to
an AutomaticJobRegistrar instance being created earlier than necessary.
This commits tightens up AutomaticJobRegistrar so that it only listens
to ApplicationContextEvents.
Closes BATCH-2506
See https://github.com/spring-projects/spring-boot/issues/2395
It has been tested with Jackson 2.3.3 which is the Jackson version
used with the Spring dependency.
Tests have been updated to use Hamcrest matchers and made a bit more reusable.
