Bug 5374

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

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:
http://static.springsource.org/spring-batch/reference/html/configureStep.html#conditionalFlow

I thought that what the example showed here:

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

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
Scott,

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>
        <batch:step id="step2" next="step3">
            <batch:tasklet ref="failureTasklet"/>
        </batch:step>
        <batch:step id="step3">
            <batch:tasklet ref="failureTasklet"/>
        </batch:step>
    </batch:job>

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:

https://java.net/projects/jbatch/downloads/download/JSR%20352%20v1.0%20Maintenance%20Release%2020140110%20Draft.TrackChanges.pdf

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.