--------------Original Comment History----------------------------
Comment from = cf126330 on 2016-09-14 15:00:35 +0000
Applications can set step exit status by calling StepContext.setExitStatus(...). And a batchlet process() method can return a string value as the step exit status, too. We need to have rules how to reconcile the 2 sources of step exit status.
In testSplitFlowContextPropagation test, inside the test batchlet's process() method, it calls stepContext.setExitStatus() to record test data, and returns something else (GOOD_EXIT_STATUS).
The test expects the eventual step exit status to be the test data set to the stepContext inside batchlet process() method.
But in JBeret, the step exit status is set to the return value of batchlet process() method, because the process method return value happens after setExitStatus() calls.
The test expects the eventual step exit status to be the test data set to
the stepContext inside batchlet process() method.
But in JBeret, the step exit status is set to the return value of batchlet
process() method, because the process method return value happens after
setExitStatus() calls.
So, is there a rule for reconciling these 2 sources of step exit status?
Originally opened as bug 112710 by cf126330
--------------Original Comment History---------------------------- Comment from = cf126330 on 2016-09-14 15:00:35 +0000
Applications can set step exit status by calling StepContext.setExitStatus(...). And a batchlet process() method can return a string value as the step exit status, too. We need to have rules how to reconcile the 2 sources of step exit status.
In testSplitFlowContextPropagation test, inside the test batchlet's process() method, it calls stepContext.setExitStatus() to record test data, and returns something else (GOOD_EXIT_STATUS).
The test expects the eventual step exit status to be the test data set to the stepContext inside batchlet process() method.
But in JBeret, the step exit status is set to the return value of batchlet process() method, because the process method return value happens after setExitStatus() calls.
See spec list discussion: https://java.net/projects/jbatch/lists/public/archive/2016-09/message/0
Note that the java.net link is bad, but we had it archived. Pasting it here:
From Cheng Fang 13 Sep 2016
In testSplitFlowContextPropagation https://github.com/WASdev/standards.jsr352.tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/tests/jslxml/ParallelContextPropagationTests.java#L122 test, inside the test batchlet's process https://github.com/WASdev/standards.jsr352.tck/blob/master/com.ibm.jbatch.tck/src/main/java/com/ibm/jbatch/tck/artifacts/inner/ParallelContextPropagationArtifacts.java#L54() method, it calls stepContext.setExitStatus() to record test data, and returns something else (GOOD_EXIT_STATUS).
The test expects the eventual step exit status to be the test data set to the stepContext inside batchlet process() method.
But in JBeret, the step exit status is set to the return value of batchlet process() method, because the process method return value happens after setExitStatus() calls.
So, is there a rule for reconciling these 2 sources of step exit status?