I want to integrate a batch console management that lists all available jobs and offers links to start/stop/schedule jobs. Regarding this, I have many questions (please correct me if any assumption is wrong) :

  1. What is the typical (recommended use) for the batch environment? One environment per batch (a job launcher, facade, etc with a configured jobConfigurationName and autostart=true) or a generic environement without configured jobName and invoked solely using the run(String name) or run(JobIdentifier id) (this second option will certainely require TaskExecutorJobLauncher, otherwise jobs can only be invoked serially).
  2. As I understand, the JobLauncher is the primary class for my purpose. Is there a single instance of this class or is there one instance per job execution ? i.e. is the job launcher a singleton or a protoype?
  3. In order to schedule jobs, shall I use the TaskExecutorJobLauncher and provide a TaskExecutor with scheduling capabilities, or shall I encapsulate the JobLauncher in a scheduler?


Maybe all above options are possible, but which one is recommended or, better stated, which one represents best your idea when you designed the framework?

In point 3 from above, if I use the TaskExecutor inside the JobLauncher, I might encounter problems when I schedule a job for a delayed execution, then invoke stop() : NoSuchJobConfigurationException because the job is not registered yet. Is this the way it should be, i.e. invoking start() does not ensure that I can invoke stop() right after ? In this case, I will certainely need to extend the JobLauncher for special delayed execution, by registering Futures in a map and cancelling one of them on stop() invocation, instead of directly stopping the container.

Thanks in advance for your responses.