| [jakartabatch-dev] CDITests.testCDIInjectContexts and DependentScopedBatchletContexts batchlet |
| I have 2 questions about the TCK test CDITests.testCDIInjectContexts: 1, this test uses a batchlet DependentScopedBatchletContexts which injects JobContext and StepContext in various ways (field, constructor, and method injections). But all fields are already annotated with @Inject, which means they are already field-injected. So even if one implementation does not support method or constructor injection, the target field already contains the expected value. Is this an oversight or specific reason? 2, step exit status from process() method return value, or StepContext.setExitStatus(...)? A batchlet step can get its exit status from either process() method return value, or StepContext.setExitStatus(), but which takes precedence? The test assumes setExitStatus(...) wins and ignore the return value. I couldn't find a clear language in the spec. One may argue that setExitStatus() call is more explicit so it should win. But return value from process() is equally strong in this regard, since this is exactly the purpose of this return value, and no other use of this return value exists. If we allow the last call to win, then the return value happens last after all setExitStatus(...) calls. From a user's point of view, after calling setExitStatus(...), more processing happens, which may produce more up-to-date exit status, presented as the return value. What do you think? |