Bug 4707 - TCK FlowTransitioningTests issues
TCK FlowTransitioningTests issues
Product: jbatch
Classification: Unclassified
Component: source
All All
: P5 normal
: ---
Assigned To: ScottKurz
Depends on:
  Show dependency treegraph
Reported: 2013-02-23 02:42 UTC by mminella
Modified: 2013-08-29 16:49 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
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

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

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.