Bugzilla – Bug 5372
Evaluation order of multiple transition elements
Last modified: 2016-03-17 16:10:38 UTC
See public ML discussion "evaluation order of multiple transition elements" (though it's a lot to read through).
The question specific to this bug is indeed the subject of the email thread, the "evaluation order of multiple transition elements".
(From there I brought up other, related issues, like co-existence of the @next attribute with transition elements as well as exception flow, which could end up getting addressed separately.)
Let me note for what it's worth that this might be a small or a moot point with respect to the TCK. I.e. if we have any TCK tests that would fail based on the interpretation of this question, it's only a couple.
So where do we stand on this issue? It's a long thread and I'd like to understand (from the perspective of this specific bug) what the proposed solution is.
Having broken out from the original email thread the aspects captured in bugs 5373, 5374, we could discuss the ordering issue in this bug separately.
So this is a "logically separate" response though obviously right on the heels of my email response to the other two issues.
Again, I'm not sure or don't recall if there is truly a TCK impact; I'm marking this as "tck_challenge" since I think it's critical to address in 1.0 and can't wait until 1.1 for clarification.
Proposal: The transition elements are matched in order. They will not be reordered most to least specific.
The main contrary argument would be the impact to existing SpringBatch XML.
Something like this will be broken by the proposed spec interpretation:
<next on="*" to="step2"/>
<next on="FAILED" to="recoverStep"/>
However, while this is a simple example, and may be the 95% case (or whatever number, I'm just guessing), it's problematic to state a more general rule for all possible expression comparisons.
The SpringBatch API referenced earlier in this email thread, which provides this function in SB according to Michael, doesn't necessarily seem to provide a complete definition we could paste in the spec.
Assuming there is a complete ruleset, it's one more thing for an implementation provider and JSL author to learn. It seems simpler to just say "in order" and therefore more desirable.
We're fine with the above proposal.
1) Deleted last paragraph in section 8.2.5.
"See section 8.6 for more details about transition elements and section 8.9 for details on transitioning rules."
2) In new section 8.9 (added more for bugs 5373, 5374), added subsection 8.9.1:
8.9.1 Combining Transition Elements
Any combination of transition elements can be included at the end of a step, flow, or decision definition. Combinations can include zero, one, or more than one instance of a single type of execution element, e.g. ‘next’.
Transition elements are evaluated in sequential order as they occur within the JSL document. I.e. the appropriate exit status is compared with the ‘on’ attribute value of the first transition element in the sequence and, if it matches, then the corresponding transition is perfomed, and the rest of the transition elements are ignored. If not, the second transition element is evaluated, etc.
<next on="RC0" to=”Step2”/>
<next on="RC4" to=”Step3”/>
<end on="RC4" exit-status=”DONE”/>
<fail on="*"/> <!-- Matches anything, so only makes sense as last transition element-->
I wonder if this might be covered already, but leaving it open to consider new tests in TCK.
Will track in: