Since Spring Cloud Task depends on Spring Boot, it should obtain the
version of dependencies managed by Spring Boot from Spring Boot. This
commit removes the explict configuration of Spring Batch's version in
the Spring Cloud Task pom and instead delegates that to Spring Boot.
- Make exit code nullable and only update of execution status can make it a valid integer
- Update JDBC create/start task execution queries to have exitCode as `null` values
- Update tests to validate/verify the appropirate exit code values for create/start/complete task executions
On merge had to add a pause to the TaskLauncherSinkTests to wait for the task to complete successfully Before we assumed that 0 was a satisfactory result meaning it was either running or completed. Now with the null being returned it could be zero or null. So we have to wait for the task to complete.
Replaced TaskListenerExecutorFactory with TaskListenerExecutorObjectProviderTests. This delays the need to acquire a bean till it is needed vs at application event time.
resolves#448
- Add the ability to retrieve the last TaskExecution to:
- MapTaskExecutionDao
- JdbcTaskExecutionDao
- Refactor `JdbcTaskExecutionDao` and use `NamedParameterJdbcTemplate` for all persistence store calls
- Add the following TaskExecution methods to TaskExplorer:
- getLatestTaskExecutionsByTaskNames
- getLatestTaskExecutionForTaskName
- Add Tests
- Ensure that code is JDK7 compatible due to backporting needs
- Ensure commit backports to 1.2.x
Polishing on tests during merge
If a user adds spring-cloud-starter-config to the dependencies it has to add a proxy for the datasource else the Hikari connection pool pukes.
resolves#407
This PR adds a sample that illustrates the use of multiple DataSources
in a single Spring Cloud Task application.
Resolves#413
Updated based on code review
I corrected spelling and grammar and gave it a voice (flat, corporate) consistent with our other docs. I added a couple TODOs where I thought another sample would help.
Incorporated Glenn Renfro's comments
Glenn gave my work a thorough review (thanks, Glenn!). This commit incorporates his changes.
One more change
I missed one of Glenn's fixes (by forgetting to save one last time before the previous commit). I have corrected that oversight
This commit adds the ability to configure the order for the
TaskJobLauncherCommandLineRunner. It also provides minor polish on a
few other code review related items.
Per Stephane's comment on the related issue, Spring Boot starters are
expected to bring in the spring-boot-starter. Before this commit, the
Spring Cloud task starter did not, which lead to incorrect logging
configuration. This commit addresses that issue.
Resolves SCT-359
resolves#81
Using LockRegistryLeaderInitiator to do leadership election.
When task is started and singleInstanceEnabled isset to true then we use leader election
to determine if a task needs to be started.
Error Event Name had to be updated
