Bug 5374

Summary: Details of exception handling (by container)
Product: jbatch Reporter: ScottKurz
Component: TCKAssignee: ScottKurz
Severity: normal CC: issues, mminella
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: Windows   

Description ScottKurz 2013-09-09 21:21:16 UTC
The last issue arising from the ML discussion "evaluation order of multiple transition elements".   

This would be a more major issue if it weren't for the fact that, I believe, for your typical JSL this won't really be an issue (i.e. the difference btw the RI behavior today and another behavior won't differ for most JSLs).
Comment 1 ScottKurz 2013-09-11 18:30:35 UTC
Did a bit more investigation here.  Michael, it would be helpful if you could confirm.

First, let me extract what I'm calling the "3rd issue" from the email and paste it here.


As we were trying to follow the SB behavior here, Michael, could you please chime in and clarify what the 
behavior is regarding failing/transitioning in the case that an exception is thrown reaching back to the container?

Again, though I failed to communicate this in an open discussion, I actually thought we were following
the SB behavior in implementing the RI in the manner we did.

That's based on this link:

I thought that what the example showed here:

    <step id="stepA" parent="s1">
        <next on="*" to="stepB" />
        <next on="FAILED" to="stepC" />

was a sort of "catching an exception in a JSL transition element".    I.e. an exception is thrown, so step 
exit status defaults to FAILED, which is then subject to transition element matching.


What I found was that SpringBatch 2.2.1 did indeed seem to behave as the RI does in this respect, at least in the single sample I ran.
Comment 2 mminella 2013-09-16 16:38:45 UTC

For the scenario you are isolating here, you are correct.  In a Spring Batch job configured as:

    <batch:job id="personJob">
        <batch:step id="step1">
            <batch:tasklet ref="failureTasklet"/>
            <batch:next on="*" to="step3"/>
            <batch:next on="FAILURE" to="step2"/>
        <batch:step id="step2" next="step3">
            <batch:tasklet ref="failureTasklet"/>
        <batch:step id="step3">
            <batch:tasklet ref="failureTasklet"/>

if an exception is thrown in step1 and the ExitStatus is not changed by a listener, step2 will be executed.
Comment 3 mminella 2013-10-29 14:26:49 UTC
So where does this leave this issue?  It's not clear as to what the action items/outcome are from the above comments.
Comment 4 ScottKurz 2014-01-10 10:12:45 UTC
I'm going to pass on listing the individual changes here and point to the draft proposal:


This includes Word comments published to PDF.  At present there are 4 comments related to Bug 5373 which you can search through.

E.g. "Bug 5374 – pt. 2"

Use search string "5374".
Comment 5 mminella 2014-01-14 19:05:48 UTC
Section 8.7 page 47
Can we have the bullet points ordered in order of precidence?
Comment 6 ScottKurz 2014-01-14 20:33:12 UTC
(In reply to mminella from comment #5)
> Section 8.7 page 47
> Can we have the bullet points ordered in order of precidence?

Do you mean the three items listed here:

A job execution will end under the following conditions:

1. A job-level execution element....



I don't see there being a precedence order here.  Those three conditions are peers, you could say.    Or did you mean something else?
Comment 7 ScottKurz 2015-09-03 21:21:11 UTC
Moving to TCK as I recall this being under-tested.