Bug 4707

Summary: TCK FlowTransitioningTests issues
Product: jbatch Reporter: mminella
Component: sourceAssignee: ScottKurz
Status: RESOLVED FIXED    
Severity: normal CC: cvignola, issues, ScottKurz
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description mminella 2013-02-23 02:42:54 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.
Comment 1 ScottKurz 2013-02-23 16:04:15 UTC
Michael,

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???
Comment 2 mminella 2013-02-25 17:41:02 UTC
Scott,

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.
Comment 3 cvignola 2013-08-29 16:49:21 UTC
The spec (in Section 13.1) now requires either JobStartException or a FAILED execution, addressing this point.