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 iTunes, Google Play, Stitcher, or use the link to the RSS feed.
-----
Setting the exit status for a job is, technically, a pretty easy thing to do. You just inject the JobContext and call the setExitStatus method passing whatever the status you want to set. No problem.
Well, we’ve talked earlier about how the exit status is just a string and you can set it to anything you want. But this status is going to get carried out to whatever is managing your batch jobs and you want the final status of the job to be something that system can handle. It may be expecting something basic like “0” or “8” to indicate success or failure. It might tolerate “OK” or even “ok” or “Ok”. But “Yippee-Kai-Yay” is probably not going to work. Get in touch with whoever owns the thing that’s going to control your batch job and find out what sort of thing they are expecting. If you talk them into taking that last one, let me know.
We haven’t talked too much about where you set it. In fact, you can set the batch job’s exit status from ANY artifact that gets control in the whole life of the job. The beforeJob method in a Job Listener (probably the earliest thing that can possibly get control in the job) could decide how this job is going to turn out and set it. Maybe you’re just optimistic.
For our sample this time we’ve got a nice simple one step job where the batchlet sets the job’s exit status and then completes. But then we’ve got a Step Listener whose afterStep method gets control and changes the value. And finally we have a Job Listener whose afterJob method gets control and changes it again.
At each step along the way we use the getExitStatus method to find out what the status was before we changed it. That’s handy because you might want to just modify the existing status in some way because this artifact has more or different information than the artifact that already set a value. It is just a String so you can concatenate things together – if that will make sense to whoever or whatever sees it.
If nobody has set the Exit Status at all, the current value is null. That’s handy too in case you only want to set a value if nothing else in the job has set it. That’s how the batch container knows to set the Exit Status to the Batch Status value at the end of the job if it hasn’t been set yet. If you use a Decider (coming up) it will set the Job Exit Status for you too, so watch out for that.
Our sample parts this time are: SettingJobExitStatus.xml, BatchletSetJobStatus.java, StepListenerSetJobStatus.java, and JobListenerSetJobStatus.java. Each artifact reports the job exit status on entry and then tells you what it set it to.
The sample parts are here: https://github.com/follisd/batch-samples