WebSphere Application Server & Liberty

Jakarta Batch Post 118: Job Parameters in Job Context

By David Follis posted Wed December 09, 2020 08:39 AM

This post is part of a series delving into the details of the JSR-352 (Java Batch) specification. Each post examines a very specific part of the specification and looks at how it works and how you might use it in a real batch application.

To start at the beginning, follow the link to the first post.

The next post in the series is here.

This series is also available as a podcast on iTunesGoogle PlayStitcher, or use the link to the RSS feed

The issue can be found here.

When a job is submitted the submitter can choose to specify job parameters.  These parameters are name/value pairs where both are Strings.  It is essentially a Properties object. 

Typically these parameters are used to set job properties.  Job properties are defined in the JSL in a properties element and, again, consist of name/value pairs where the value is always a String.  The syntax allows for a default value to be provided if the job parameter on which the property is based was not set by the submitter.

Job parameters are frequently used as values for properties of other batch artifacts and injected into them at runtime.  For example, a chunk step might have a reader that needs to know the file name to read from.  That file might be provided to the reader as a property whose value comes from a job parameter (either directly or via a job property set from the job parameter). 

A batch artifact can also just access the job properties directly using the Job Context.  The getProperties method will return a Properties object containing all the job properties specified in the JSL (and possibly some extra ones depending on the implementation).

However, there’s no way to get to the actual job parameters that were specified by the submitter.  You have to have JSL that assigns them all to job properties.  Which means that the JSL has to be aware of all the possible things the submitter might specify.

The proposal here is to add a method to the Job Context that would return a Properties object with the entire set of job parameters specified by the submitter.  This could eliminate a lot of extraneous JSL that is just there to convert parameters into properties.

We would probably want to allow implementations to tuck in extra parameters so you shouldn’t be surprised to find things in there that the submitter didn’t explicitly specify. 

We’d also want to be clear (as we are with getProperties) that the object returned isn’t the actual job parameters object, so you can’t add/delete/change things in it and expect other batch artifacts in the same job to see your updates.

Sound interesting?  Follow the link above and join in the discussion.