When use Spring Boot with Spring Batch, currently we use command line arguments to transmit job parameters. This is a typical way to launch a job with specified job parameters.

java -jar fooJobApp.jar param1=v1,java.lang.String,true param2=100,java.lang.Long,false

This command builds a parameter named param1 which the type is java.lang.String and the identifying flag is true, and a parameter named param2 which the type is java.lang.Long and the identifying flag is false.

I think there are some inconvenience like, - Command line becomes too long if there are many job parameters. - Change job parameter needs to restart application, and cannot integrate with configuration center like Spring Cloud Config.

So, it would be nice if ConfigurationProperties is supported to specify job parameters, maybe as fllows:

spring.batch.job.parameters.xxJob[0].name = param1
spring.batch.job.parameters.xxJob[0].type = java.lang.String
spring.batch.job.parameters.xxJob[0].value = v1
spring.batch.job.parameters.xxJob[0].identifying = true
spring.batch.job.parameters.xxJob[1].name = param2
spring.batch.job.parameters.xxJob[1].type = java.lang.Long
spring.batch.job.parameters.xxJob[1].value = 100

Comment From: wilkinsona

WDYT, @fmbenhassine?

Comment From: fmbenhassine

I think there is a difference between "technical" parameters (like chunk size, database connection pool size, thread pool size, etc) which are specified at configuration time and "business" parameters (like the input file, table name, etc) which are specified at runtime.

Job parameters are designed for "business" runtime parameters, which are not suitable for a configuration file or a config server. For example, if I have a job that consumes a flat file, I would have to edit an entry in the configuration file or config server every time I need to launch the job for a different file, which is inconvenient. Moreover, such parameters can be unknown at configuration time to be specified in the file or config server. Typical examples are when job parameters are passed through a REST controller or through a message in a queue and are only resolved at runtime.

That said, I think Spring Boot is flexible enough in that area to allow custom resolution of application arguments from different sources.

Comment From: wilkinsona

Thanks, @fmbenhassine. That distinction between technical parameters and business parameters is interesting and something I hadn't considered before.

We already have some flexibility in Boot in that JobLauncherApplicationRunner is a public non-final class and the auto-configured runner will back off if an app defines its own. This means that you can define a bean that's a subclass of JobLauncherApplicationRunner and override its run(String... args) method. The args are the application's command line arguments but you are free to add to those with whatever you need from any source that you choose to implement and then delegate to launchJobFromProperties(Properties).

Would that fit your needs, @lcmarvin? I believe your could implement your own @ConfigurationProperties-based mechanism using this approach. I think it's unlikely that would want to add built-in support for using configuration properties for this. There is perhaps some scope to make it slightly easier by having a callback interface that deals specifically with creating the Properties but the benefit would be fairly marginal.

Comment From: lcmarvin

Thanks for the reply and suggestion, It seems that I haven't understand the position of job parameter's design before.

I close the issue with my thanks again 😄!