Make use of Batch 4.0 M4's new API for accessing job parameters

[diegolovison]

We are building an application that have dozens jobs.
Each job is configured to run in a scheduled way.

@Autowired
private JobLauncher jobLauncher;

@Scheduled(cron = "0 0/5 * * * ?")
public void run() throws Exception {

    jobLauncher.run(myJob(), new JobParameters());
}

@Bean
public Job myJob() {
    return jobBuilders.get("myJob")
        .incrementer(new RunIdIncrementer())
        .flow(jobStep1())
        .end()
        .build();
}

In this case, "myJob" will run once because we need to properly configure the JobParameters.

There is an excelent example how to propertly configure the parameters in the class JobLauncherCommandLineRunner.

What I am suggesting here is split the logic in the class JobLauncherCommandLineRunner.
Creating another class like "FooJobLauncher" that will have the business logic to execute the job getting the next parameter.
The class JobLauncherCommandLineRunner will use the "FooJobLauncher".

In this way I can autowired "FooJobLauncher" in my class without worrying with the next parameters logic.

I can create a merge request if the team agree with the change. I only need to know a better name for "FooJobLauncher".

Thanks

[wilkinsona]

I'm not 100% sure I've understood which logic it is that you'd like to be able to reuse. Is it what's done in getNextJobParameters(Job, JobParameters)? That, to me, looks like a good candidate for factoring out into a separate class, particularly as it's the only place in JobLauncherCommandLineRunner that makes use of the JobExplorer field.

[dsyer]

I think @wilkinsona is correct - the OP wants to split out the logic in JobLauncherCommandLineRunner.getNextJobParameters(Job, JobParameters) so he can use it in his own @Scheduled method.
It's a private method with some useful logic, and arguably it ought to be in Spring Batch, but Batch usually pushes these kinds of things off to users, so maybe it is better here.

[wilkinsona]

Thanks, @dsyer. @mminella what do you think? Is this method something that you could add to Batch, or do you think it's better-suited to living in Boot or the user's own code?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[mminella]

I'm fine with pulling this into batch. And 4.0 would be a good opportunity to do so. I've created this Jira item to track us moving it over: https://jira.spring.io/browse/BATCH-2640

[wilkinsona]

Neat. Thanks, @mminella. Let's use this issue to move onto the Batch-provided version of what's currently in Boot.

[diegolovison]

The private method JobParameters merge(JobParameters parameters, Map<String, JobParameter> additionals) on class JobLauncherCommandLineRunner is a good candidate to be public as well.

[wilkinsona]

@diegolovison To reduce the chance of it being missed, I'd recommend making that suggestion on BATCH-2640. It's tracking the Spring Batch changes.

[mminella]

Just an update, I just merged BATCH-2640. FYI, the merge capability is already available on the JobParametersBuilder which is where we added this functionality.