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.
We’re working our way through the various Listeners defined in the Java Batch (JSR-352) specification. Last time we looked at the Job Listener and this time we’ll come inwards a little bit and have a look at the Step Listener.
As you might expect, the Step Listener gets control around a step. The Java class that implements the listener is defined in the JSL as part of the step. That means that you don’t define one giant step listener class that gets control for every step in the job. Instead, for any step that needs a listener, you can define a separate implementation. If you want to.
Remember that in the JSL you are just specifying a step-level listener and the batch container determines what listener it is and when to give it control based on the interface(s) it implements. So a Step Listener can do double-duty as some other Listener type if you want, by implementing multiple Listener interfaces.
Ok, so what methods do we have? Just the two: beforeStep and afterStep. These, obviously, get control before any other processing happens in the step and after it is all done. The other step-level Listeners we’ll discuss all get control inside of these two methods.
The beforeStep, much like the beforeJob method on the Job Listener, is your chance to do initialization or otherwise do any pre-actual-step processing you need to do. An exception thrown here will fail the job, so if something is wrong that you can detect before the step gets going you can kill it right here.
The afterStep method is there to let you clean up after the step. It gets control even if there is an unhandled exception thrown during the processing of the step. This means you can rely on it to do any clean up you need, even if things don’t go well.
And, as with the Job Listener afterJob method, this is your chance to set Exit Status. Remember that each step has a separate Exit Status value. And remember that the step Exit Status has nothing to do with the Job Exit Status. The step Exit Status might be used to determine which step executes next (if any). Using the Step Context to set an Exit Status value for the step from the Step Listener afterStep method is pretty common. This is your chance, after everything is over and done, to decide how things turned out. But remember – nothing gets passed to the afterStep method. Any information it uses to make a decision has to come through the Step Context or some other communication mechanism between parts of the step processing.
The remaining listeners all relate to processing in a chunk step. We’ll get to those after we’ve talked about chunk processing. But we have a few other things to get to first…