|
So here's a plan:
* Move the *JobLauncher features (concurrency and thread interruption) into helpers and/or subclasses in the JobExecutorFacade. Use JobExecutionListener where appropriate to register the context for the job with a helper (so the helpers have to be recognised as listeners and added to the chain). * Handle stop() methods internally with ApplicationEvent having the JobIdentifier as a payload. Question: how many such methods to expose - ideally as few as possible - maybe eventually only one with JobIdenitifer parameter again (as per JobExecutorFacade currently)? * Kill the JobLauncher interface. I like the idea of removing the JobLauncher interface, and moving it's responsibility into the JobExecutorFacade (side note: is there anyway we can think about renaming this now that has more responsibility? Facade still doesn't sound right to me) I'm assuming if the JobIdentifier is the payload of an Event, then we would simply be creating or own version of ApplicationEvent?
All the external APIs are now where we wanted them. The internal stuff with stop signals is unimplemented (possibly unneeded, since the old functionality from before the refactoring is still there). Marking as resolved.
N.B. if anyone is following this issue but not the source code... the JobLauncher interface survived, but the JobExecutorFacade became private (where it belonged anyway). We also didn't need to bother with the enhanced stop() functionality (it might come later if anyone asks). |
||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Closed
Critical
JobExecutor should return a JobExecution (which itself contains the ExitStatus)
Really this needs to go further - it's the JobExecutorFacade that might ultimately need to bye able to return asynchronously (e.g. with a TaskExecutorJobExecutor TBD), so the layer above seems like it might be redundant. I'm questioning whether there is a need for the JobLauncher interface at all. But the Thread.interrupt() in SimpleJobLanucher would not sit well in a JobExecutorFacade implementation.