Before this commit, JobParametersBuilder#getNextJobParameters was checking
for restartability conditions. This is not only already done by the
JobLauncher, but also makes it inconsistent with the behaviour of
CommandLineJobRunner when used with "-next" option and
JobOperator#startNextInstance, which is starting the next instance in
sequence based on the incrementer without dealing with restartability.
This commit fixes the JobParametersBuilder#getNextJobParameters to behave
like the CommandLineJobRunner and JobOperator in regards to starting
the next instance.
Resolves BATCH-2711
This is to exclude from capturing erroneous Job Executions. An example is
whenever a TaskRejectedException is thrown after submitting to the
taskExecutor in SimpleJobLauncher#run(), the JobExecution is left without
a Start or End Time. Also related tests are fixed.
Resolves BATCH-2675
This is required to be able to test against Java 11. In Java 11, JAXB is
removed from the JDK (See http://openjdk.java.net/jeps/320). This commit
fixes errors of type:
```
StaxEventItemWriterTests.java:22: error: package javax.xml.bind.annotation
does not exist: import javax.xml.bind.annotation.XmlRootElement;
```
Two important points (from JEP 320) to note about this commit:
* `Another risk of removing the Java EE modules is that applications
which already migrated from JDK 6, 7, or 8, to JDK 9, will not start if
they use the command line flag --add-modules java.se.ee,
--add-modules java.xml.bind, etc.` This commit removes the need to add
the flag `--add-modules java.xml.bind`. This removal does not impact
building on Java 9 since JAXB is in the class path now.
* `The Reference Implementations (RIs) of JAX-WS and JAXB are a good
starting point because they are complete replacements for the
java.xml.ws and java.xml.bind modules in JDK 9. The RIs are available
as Maven artifacts: (note that they must be deployed on the class path)`
This commit adds JAXB to the test class path where needed.
Issue: BATCH-2757
1. The first issue is:
```
> Task :api
DefaultBatchConfigurer.java:18: error: cannot find symbol
import javax.annotation.PostConstruct;
^
symbol: class PostConstruct
location: package javax.annotation
DataSourceConfiguration.java:18: error: cannot find symbol
import javax.annotation.PostConstruct;
^
symbol: class PostConstruct
location: package javax.annotation
DefaultBatchConfigurer.java:94: error: cannot find symbol
@PostConstruct
^
symbol: class PostConstruct
location: class DefaultBatchConfigurer
DataSourceConfiguration.java:46: error: cannot find symbol
@PostConstruct
^
symbol: class PostConstruct
location: class DataSourceConfiguration
4 errors
```
This issue is fixed by adding the `javax.annotation-api` dependency
2. The second issue is:
```
javadoc: error - An internal exception has occurred.
(com.sun.tools.javac.code.ClassFinder$BadClassFile: bad class file:
/org/springframework/batch/core/configuration/support/
GenericApplicationContextFactory$ResourceAnnotationApplicationContext$1.class
class file contains malformed variable arity method:
GenericApplicationContextFactory$ResourceAnnotationApplicationContext$1
Please remove or make sure it appears in the correct subdirectory of the classpath.)
```
The workaround to this issue is to use a named inner class instead of
an anonymous one.
Upgrade jacoco to version 0.8.2
Fix failing tests on Java 9
* `javax.xml.bind` is no longer contained in the default class path in
Java SE 9. This commit adds the module `java.xml.bind` to the JVM args
for tests
* JsrBeanDefinitionDocumentReaderTests are failing because
`ClassLoader.class.getResourceAsStream` has a different behaviour on Java 9.
According to `https://stackoverflow.com/a/45173837/5019386`, it's best to
use the resource-lookup methods in Class rather than those in ClassLoader.
* DefaultJobParametersExtractorJobParametersTests#testGetAllJobParameters
is failing because jobParameters.toString() returns "{foo=bar, spam=bucket}"
on Java 9 and "{spam=bucket, foo=bar}" on Java 8. The fix asserts that
jobParameters contains the expected key/value pairs without relying on the
toString method
JIRA: BATCH-2751
Before this commit, it was not possible to override the transaction
manager by subclassing DefaultBatchConfigurer and overriding the
getTransactionManager method.
This commit uses the getTransactionManager method in the initialize method
in order to take into account the transaction manager provided by the user.
Resolves BATCH-2294
The method is named as "getStartable". "getStartable" is prone to obtain something. "isStartable" is a query asking whether the stepExecution is startable, which describes what the method is doning. So, "isStartable" should be more intuitive.
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
