Cheng,
1 - That looks like an oversight, and I think the fields should not include `@Inject`.
2 - Now that you mention this, I fear we have been through this exact scenario before. Having moved Git repos, issues, & ML, I’m not going to bother trying to confirm, though.
But I vaguely remember discussing this and I noticed if I change the jbatch behavior all the other tests pass.
So does JBeret have the Batchlet return value take precedence over a StepContext.setExitStatus() value set elsewhere?
If I’m remembering correctly, it was an embarrassing thing to have noticed then, but perhaps we already felt it was too late to fix then. Or maybe this is a new issue and we’ve diverged in behavior all these years.
In any case, it seems like we would ideally then go through the processes for updating the TCK (possibly including the challenge process) as defined:
Maybe we could see what else you find though.
Thanks,
Scott
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
This Message Is From an External Sender | This message came from outside your organization. |
|
|
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.
