Bug 5372 - Evaluation order of multiple transition elements
Evaluation order of multiple transition elements
Product: jbatch
Classification: Unclassified
Component: TCK
All All
: P5 normal
: ---
Assigned To: ScottKurz
Depends on:
  Show dependency treegraph
Reported: 2013-09-09 21:13 UTC by ScottKurz
Modified: 2016-03-17 16:10 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2013-09-09 21:13:42 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.
Comment 1 mminella 2013-10-29 16:03:15 UTC
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.
Comment 2 ScottKurz 2013-11-10 00:05:56 UTC
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:

<step id="step1">
    <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.
Comment 3 mminella 2013-11-14 16:42:12 UTC
We're fine with the above proposal.
Comment 4 ScottKurz 2014-01-10 10:07:25 UTC
1) Deleted last paragraph in section 8.2.5.

Replaced with:

 "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.
<step id="Step1">
	<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-->
Comment 5 ScottKurz 2015-09-03 20:55:20 UTC
I wonder if this might be covered already, but leaving it open to consider new tests in TCK.
Comment 6 ScottKurz 2016-03-17 16:10:38 UTC
Will track in: