WebSphere Application Server

JSR-352 (Java Batch) Post #20: Setting and Using Job Properties

By David Follis posted Wed November 14, 2018 08:15 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.

Every programming artifact in the Java Batch environment allows you to specify properties in the JSL that will be injected into that artifact.  You can have JSL properties that get injected into your batchlet, your ItemReader, your listener (of whatever type), etc.  Job Properties are unique in that they don’t get directly injected anywhere. 


A Job Property exists to be used as a variable whose value is accessible across the entire job.  You can use it to substitute a value into another property that is injected into an artifact.


For example, suppose you have a file that is used as input by several steps in the job.  You don’t want to hard-code the path to the file in the application.  You want to inject it into the application from the JSL.  But you also don’t want to put the same value as a property in several different places in the same JSL.  The solution is to set the path as a job property and then use that value to set the properties that are injected into the different artifacts in the job. 


You can also set a job property from a job parameter.  This makes a nice way to introduce the value of the parameter into the job in a manner that makes it available to the whole job.  The ability to set a default value in the JSL also means you don’t have to write code, possibly in several places, to know the default.  The application code can assume a value always gets set.


Before we go, I thought I’d also remind you that all the Job Properties are available programmatically from within the job by accessing the JobContext object.  It is probably cleaner to have the properties used to substitute into batch artifact properties that are then injected which separates the application code from knowing too much about the job level properties.  But if the need arises, it is still possible to get them. 


That’s it for this time.  You might be wondering about all these parameters and properties and default values and how you actually code these in the JSL.  Good question.  We’ll take that on next time…