|
[
Permlink
| « Hide
]
Dave Syer added a comment - 31/Mar/08 07:50 AM
The workaround is to change the BatchStatus manually in the StepExecutionListener.
Is this issue really a blocker for 1.0.1? There seems to be a reasonable workaround and the way things work currently is "by design", so I feel like we should leave it for 1.1
Actually, on reflection, the workaround only works if you also set the JobExecution.status to FAILED, otherwise there are going to be issues on restart (the job will think it was successful and it wasn't). That is getting quite ugly for anyone relying on being able to fail a job from a listener. I think it should be possible to fix this without any surprises for anyone else.
In the context of
listener.afterStep() call moved from catch block to the end of the try block - exception thrown in listener therefore causes the step to fail.
I tried throwing the RuntimeException from afterStep of step-2 (so as to terminate the job and not to proceed with step-3). However, this exception gets handled in ItemOrientedStep and continues with the step-3.
//stepExecution.setTerminateOnly(); is commented out....... @Hiren: are you using the trunk version (note the fix is not included in 1.0.0, it is for 1.0.1)? There are tests that make sure throwing exception in afterStep fails the step, so I believe it works correctly.
@Robert: Yes, i am using spring-batch-core-1.0.0.jar. Shall i get 1.0.1 or use the manual approach as suggested above?
@Hiren: I'd suggest using the trunk version - 1.0.1 is most likely to be released in less than 2 weeks from now, so you'll be back in safe position using official release reasonably soon.
How do i get the release 1.0.1? I don't see it anywhere?
The 1.0.1 release should be out today.
|
||||||||||||||||||||||||||||||||||||||||||||||