Bug 4647 - More detail on JobStartException / JobRestartException? Job - abstract / restartable
More detail on JobStartException / JobRestartException? Job - abstract / res...
Product: jbatch
Classification: Unclassified
Component: source
PC Windows
: P5 enhancement
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2013-02-06 13:12 UTC by ScottKurz
Modified: 2013-03-01 18:23 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2013-02-06 13:12:16 UTC
There's not much detail on when exactly a runtime should throw  JobStartException / JobRestartException?

I can see some value in having a general-type exception that an impl might throw for impl-specific reasons... 

As we're working on the RI/TCK we are faced with:

1a. should job start of an abstract job (or a job with an abstract step) result in a JobStartException?   

1b. should there NOT be a JobInstance or a JobExecution in this case (rather than creating a JobExecution which would end up with a batch status of FAILED).

2a. For restartable=false jobs, should this fail with a JobRestartException? 

2b. Should this NOT have a JobExecution for the restart?


The spec COULD choose to say something both about the specific exception associated with abstract jobs (or steps) and restartable=false.   It could also choose to say something about the association between JobStartException and JobRestartException and the lack of JobInstance/JobExecution.

Or I could envision saying this is all impl-specific as a valid choice.  Maybe I'm shying away from that since that leaves me not knowing how to write the TCK test (if I don't know if there is a JobExecution or not, say).
Comment 1 cvignola 2013-03-01 18:23:33 UTC
The spec will defer most error checking to the implementation.  However, consistent with servlet 3.0, it will require a schema-valid XML before a job can start.  Job start means that a job instance and job execution are created. Problems the runtime then detects with the job definition,  including, but not limited to:

1) no executable elements (i.e. only abstract steps)

2) non-existent transitions (i.e. next="value" where "value" does not exist)

3) cycles among next values (i.e. step1:next=step2; step2:next=step1)