Dave Syer - 07/Mar/08 03:50 AM It is still an important feature to be able to always re-run a step irrespective of its history (once the job has decided top restart), but the default should be not to re-run steps that already completed. The point is that the job can ask the step to make that kind of decision, so there is at least some encapsulation. Since it is encapsulated I'm not sure this is really critical. I think we could change this in the future if we needed to (maybe not in a point release). Am I missing something?

Robert Kasanicky - 07/Mar/08 04:02 AM I've assigned high priority because the issue basically translates to "restart logic makes little sense" - I think that's serious by itself. Second, in case we fix it I assume significant positive consequences e.g. breaking the cyclic dependency between JobExecution and StepExecution and resolving the StepExecution's obscure status somewhere between entity and value object. I think the awkward restart logic is the primary client of other design obscurities, so it needs to be fixed first to get free hands for further improvements.

Dave Syer - 08/Mar/08 06:28 AM I have moved the code that deals with the last ExecutionContext up from ItemOrientedStep up to the SimpleJob, so that the TaskletStep can benefit from it as well.

Lucas Ward - 10/Mar/08 10:40 AM I'm making this as fixed, since Dave's change puts restart logic in a more logical place, and the bi-directional parent child relationship of job execution and step execution isn't going to be changed.