Bugzilla – Full Text Bug Listing
|Summary:||SPEC - JobInstance and JobExecution creation|
Description mminella 2013-03-11 22:28:02 UTC
Section 13.1 states that if the JobXML is schema valid, a JobInstance and JobExecution will be created. A JobInstance and JobExecution should only be created if the job is truly a valid job (both schema and semantically).
Comment 1 ScottKurz 2013-03-12 02:22:12 UTC
I can see the virtues of Chris' latest approach, though currently the RI is coded closer to Michael's. I now think we should remove this language from the spec altogether. It seemed that writing "prove this JSL is treated as invalid" TCK tests was the driving use case for bringing up this issue (since it's a bit of a challenge to write a test with failure if you don't know it's going to fail synchronously or not) But I move we scrap the spec statement completely and remove all "invalid"-style TCK tests. (Chris, I know this was your original thought...)
Comment 2 cvignola 2013-03-12 16:03:58 UTC
A couple thoughts on this: 1) I patterned this off z/OS batch, which I think has a good approach. With z/OS batch, they take it even farther: even non-valid JCL create the equivalent of a JobInstance/JobExecution. Z/OS batch writes a log for every job. If there is any kind of problem with the job, you can always debug from the joblog. In the case of the JSR, I tightened that approach to require that the JSL be syntactically valid before creating a record in the repository. The JSR does not address logging, but you can see how logging might certainly be tied to a JobInstance or JobExecution. I figured declaring when the JobInstance/JobExecution is created would set the stage. 2) If we declare semantic validation is required before the JobInstance/JobExecution is created, I think we have to define what the semantic rules are because now semantic validation enters into the programming model. I.e. semantic validation throws the same exception to the JobOperator.start/restart invoker for the same conditions across all implementations. I really wanted to avoid having to enumerate all of that in the spec, but rather leave that to implementer discretion to do at runtime. Semantic validation is natural at runtime without having to specify it all. With regard to the programming model, a job that fails runtime semantic validation is just a job in the FAILED state.
Comment 3 mminella 2013-03-12 16:12:21 UTC
@Chris The issue I have is that if you don't have a semantically valid job, then how can you have a JobInstance at all? That's like saying that you can generate a class file from a .java file that isn't semantically valid. If the definition is not semantically valid, the runtime cannot attempt to execute it and therefore no JobInstance or JobExecution should be created.
Comment 4 ScottKurz 2013-03-12 17:10:10 UTC
And why does need to be specified ? What application code (besides the TCK) would need to be rewritten when moving to an implementation with different behavior? It's not like you're going to programmatically put together some random steps and then rely on the runtime to tell you if it's semantically valid...
Comment 5 mminella 2013-03-12 18:02:13 UTC
While not ideal for portability, I'd be open to dropping the requirement that a JobInstance and JobExecution are created prior to validating that the JSL is semantically valid.
Comment 6 cvignola 2013-03-20 03:36:40 UTC
I will actually update the spec to give the implementation greater latitude. It can either: a) do semantic validation in JobOperator.start and throw JobStartException if there is a semantic violation or b) do only schema validation in JobOperator.start and delay semantic validation until job execution. Semantic violations result in a FAILED job. Note a schema-valid JSL has sufficient information to create a JobInstance and JobExecution because all that is really required is a <job> id attribute value.