Bugzilla – Bug 4707
TCK FlowTransitioningTests issues
Last modified: 2013-08-29 16:49:21 UTC
1. testFlowTransitionToStepOutOfScope - This test implies that "parsing" errors will result in a JobStartException. Is that really the way we want to handle these (is that the way the spec does)? That's a really obfuscated way of communicating that error. This test also implies that the job would actually get a JobExecution in this scenario. If the runtime cannot even parse the job, I don't think we should be providing a JobInstace/JobExecution. That's like providing a jar file when your classes don't even compile.
You and I each made related points in "Bug 4670".
I agree we shouldn't have a JobInstance/JobExecution.. but I'd though JobStartException seemed like a natural choice in this case.
That does kind of put the TCK in front of the spec in specifying this... but on the other hand it might be hard to specify all the behaviors that should result in JobStartException/JobRestartException.
What do you think the TCK should do for something like this?
Fail with any exception? Wait a few seconds and count that no new JobInstance/JobExecution for this job has been created???
I guess the JobStartException is ok. You could also make the argument for throwing a NoSuchJobException since if you cannot parse the XML, we don't know if a definition for the job exists.
The spec (in Section 13.1) now requires either JobStartException or a FAILED execution, addressing this point.