Method JobListener#afterJob called too early about jsr352

[chengfang]

Job listeners are part of the job execution, so if one of the listeners afterJob() fails, the whole job would still fail. We cannot be sure a job is fully complete and hence don't assign a endTime till all job listeners are done with afterJob().

By looking at StepExecutionRunner, I see the logic is consistent w/ JobExecutionRunner, though I haven't tested it.

[Turbokiwi]

Point 9.2.1 of the Spec says the following "A job listener receives control before and after a job execution runs". This is a little bit vague but the JavaDoc comment a few lines later is more precise: "The afterJob method receives control after the job execution ends."

Same thing for StepListeners "The afterStep method receives control after a step execution ends. " Point 9.2.2 of the Spec.

Doesn't "after the execution ends" mean, that the execution has ended at this point and therefore an exit status and endTime should be available? When an execution has ended, should/could a listener make a job fail?

[chengfang]

An old spec bug related to this issue:

Bug 4385 - Spec must specify the effect of throwing Exceptions from Listeners

Excerpt from spec 1.0-rev_A:

8.1.2 Job Level Exception Handling
Any unhandled exception thrown by a job-level listener causes the job to terminate with a batch status of FAILED. In this context, "unhandled" simply means an exception thrown by the listener back to the runtime implementation.

[chengfang]

Batch spec discussion on when job execution end time is available (March 2015):
https://java.net/projects/jbatch/lists/public/archive/2015-03/message/0

[Turbokiwi]

Saw that also. But it only says, that the endTime is null, as long as the job is not completed, stopped or failed.
According to Bug 4385 they clarified that an exception inside a listener makes a job having the status failed. The question which status the job has, when JobListener#afterJob() is called an no exception has been thrown is in my opinion not answered by the Spec.

I filed this bug now: https://java.net/bugzilla/show_bug.cgi?id=6975

[Turbokiwi]

... but reading again through point 8.7 I come to the following conclusion:
"Status COMPLETED - Batch job has ended normally ....." .... "A job execution will end under the following conditions: 1. A job-level execution element (step, flow, or split) finishes execution, without specifying a "next" attribute and without the exit status matching any transition elements. In this case, the batch status is set to COMPLETED."

And the JavaDoc of JobListener#afterJob() says: "The afterJob method receives control after the job execution ends. "

Doesn't that mean the following?:

1. a Job finishes execution after the last step
2. a finished job is given the status completed
3. JobLister#afterJob() methods are called?

[chengfang]

We can optimistically set batch status to COMPLETED after all steps and other job elements complete successfully, before calling job listeners afterJob(), to make it more consistent, even though the final job batch status may be FAILED, if afterJob() throws exception.

Before that is in place, a workaround is to end your job with a that contains a

<decision id="decision1" ref="xxx.Decider1">
        <end on="*"/>
</decision>

[Turbokiwi]

I suggest to wait for a response to the bug I filed on java.net before changing anyting. The decision-element is a neat trick. It also works with an element directly inside the last step.