Announcement Announcement Module
No announcement yet.
StepListener and JobListener Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • StepListener and JobListener


    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 ?

  • #2
    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.


    • #3
      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?


      • #4
        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 ?


        • #5
          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.


          • #6
            I have the some problem. Is easy to add a method 'onError' in JobListener. Why not do it?


            • #7
              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 [1] 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 [2].