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.
-----
The issue can be found here.
One more on the topic of listeners. We’d mentioned before that there is a job listener that gets control at the beginning and end of the entire job. We’ve also got the ability to configure a step listener for each step.
The scope of the step listener is just the step that is defined for. Remember that all the listeners for the step are just listed as listeners and the batch container figures out what type of listener it is from the interfaces it implements. You could define a dozen listeners for the step and they might all implement the step listener interface, among others. So any listener defined to the step is a listener of some sort for that step.
Back at the job level you can define listeners, but the only implementation you can have there is the job listener.
The proposal here is to allow a step listener to be defined inside a listener element at the job level. That listener would get control before and after every step in the job.
It is an interesting idea because right now each step is mostly considered to be an independent thing. The steps are joined together in a job, but the job listener is the only artifact whose scope spans the entire job.
What would you use a step listener for that could run before and after EVERY step? I suppose it could look in the Step Context to determine what step it was in and behave differently, but then you’ve really just got a different listener for every step that happens to be in the same Java code. All you’ve saved is some JSL specifying it everywhere. That could be valuable by itself, but seems a bit thin as justification.
Would you really have common processing that would apply to every (or at least most) steps? Maybe some logging processing? An update to job status somewhere when every step begins and ends (although you could also trigger that sort of thing from the Liberty batch-events support)?
I suppose it is possible there could be some common application processing that has to happen between every step in the job (or at least most of them). Maybe after each step you want to make a backup copy of the data being worked on or something like that.
Feel free to add some use cases to the issue if you can think of something.
#Batch-processing#Java-Batch#JSR#WAS#WebSphereApplicationServer(WAS)