View Full Version : StepListener and JobListener
Mar 12th, 2008, 05:48 AM
I want to do some treatments in case of errors in a step and in a job. For the step, i use the StepListener and its method :
ExitStatus onErrorInStep(StepExecution stepExecution, Throwable e);
that is called after an exception is thrown in the step execution.
But for a job, i don't know how i can do it... There is no equivalent method in the JobListener...
Can someone help me ?
Mar 12th, 2008, 08:49 AM
I'm curious about your usecase for the desired JobListener#onError, I assume there's no such method because nobody has had a good usecase for it so far.
Mar 12th, 2008, 09:42 AM
I'm not entirely sure that a JobListener.onError() makes sense. Given that jobs are a collection of steps, what errors do you expect to see in a job that you wouldn't see with a StepListener?
Mar 12th, 2008, 10:01 AM
I have a job with several steps.
Each step may have a specific treatment in case of errors (use of StepListener), but for one specific error all steps must have the same treatment, and maybe it could be do in JobListener and not on each StepListener ?
Mar 12th, 2008, 10:19 AM
I see your point about how this might make sense for a JobListener, but it seems like you could solve it pretty easily with a CompositeStepListener. Just compose the common error handler and the specific one for each step.
Mar 13th, 2008, 11:32 AM
I have the some problem. Is easy to add a method 'onError' in JobListener. Why not do it?
Mar 13th, 2008, 02:17 PM
lucas and i have been talking about it. onErrorInJob() smells a bit because there are no errors that can be intercepted by a job listener that weren't previously intercepted by a step listener. abstract bean definitions, composite listeners, etc. all solve the reuse problem well enough, so it's hard to find justification for the extra method on the job listener. i think of the job as a glorified for loop for steps and, as such, should really just report on the execution of the steps.
however, it's a good point that you may want to execute some logic after the failure of a job. so, the solution seems to be to have afterJob() execute after _any_ completion of a job, not just the successful ones. this follows the step listener anyway, so it seems to make sense. now that BATCH-419  is in, you have access to the BatchStatus and can test for any number of exit conditions and act accordingly.
The jira issue for this enhancement is BATCH-456 .
Powered by vBulletin® Version 4.2.1 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.