Add a property to all for Batch JobParameters to enable configuration via environment variables

[mminella]

Currently the only way for a user to provide Spring Batch Job Parameters is via command line args. This requested enhancement is to create a Boot property that accepts JSON to be deserialized into JobParameters. This is needed for the Kubernetes functionality when you attempt to restart a job using the shell entry point on your image. In this use case, there is no way to pass command line arguments to the application and some elements of normal parameters are not friendly to being set as environment variable names (run.id(long)=5 for example). I'd assume that the order of precedence for resolving duplicate JobParameters would follow the normal Boot conventions.

[philwebb]

If I understand the request correctly, we can probably add a field toBatchPropertiesthe update JobLauncherApplicationRunner.launchJobFromProperties to consider both command line-args and any properties.

The only thing that feels a bit odd to me is using serialized JSON for the properties. We currently delegate to JobParametersConverter which takes a Properties input. Does this mean we're going JSON -> Properties -> JobParameters?

I wonder if we can get away with a simpler format? Perhaps a list of ':' delimited items? e.g:

SPRING_BATCH_JOBPARAMETERS="run.id(long):5,foo.bar:test"

[mminella]

@philwebb

If I understand the request correctly, we can probably add a field toBatchPropertiesthe update JobLauncherApplicationRunner.launchJobFromProperties to consider both command line-args and any properties.

You understand the request correctly.

As for the use of JSON for the properties, that really was just following the model of the spring_application_json model where we are passing in all the vars in a single block. I'd prefer consistency over introducing a new format that requires users to understand/Boot needs to be able to parse/etc but I'm open to ideas here.

One other note. We'd like to get this into Boot 2.4 since it is actually impacting a SCDF use case currently. We can do the PR if that helps.

[philwebb]

One other note. We'd like to get this into Boot 2.4 since it is actually impacting a SCDF use case currently. We can do the PR if that helps.

I've reserved this one for a conference event that's happening early Oct. Hopefully someone will take this on for that, if not, I'm sure we can work together to get something in for 2.4.

[snicoll]

If I understand the request correctly, we can probably add a field toBatchPropertiesthe update JobLauncherApplicationRunner.launchJobFromProperties to consider both command line-args and any properties.

I am a bit confused. @mminella approved this but, on the other hand, talks about environment variables. I don't think we should update BatchProperties. That would expose a property in the metadata for this, which would let the user paste raw json in application.properties.

Wouldn't we detect that SPRING_BATCH_JOBPARAMETERS is set and then decode the json if necessary? Being able to specify this via environment variables or system properties but not any other property sources feels a bit inconsistent though.