| [jakartabatch-dev] discussion on JobOperator injection - should runtime provide bean? , extensions, portability, etc. |
First, a status update:
The spec and TCK have been merged with several CDI integration updates. Thank you especially to Romain for all the reviews and helpful comments.
I am very close to releasing a 2.1.0-M1 TCK. At that point, as impls experiment with the TCK we can go back and see if any of the spec/TCK updates are needed, and discuss more, etc.
(I'm sure not everyone got to review every line of spec update merged so far... so there's still a chance to make changes).
---
There's only issue we need to discuss though: injecting JobOperator.
My general thought was to establish that a runtime should provide a JobOperator while saying as little about the mechanism as possible.
This mirrors the approach we did for the BatchRuntime.getJobOperator() API, as we did not specify the extension mechanism here either.
(Though of course the javax/jakarta Maven artifacts did use ServiceLoader and so arguably provide a "de facto standard"?)
So I kept the language vague in the PR: https://github.com/eclipse-ee4j/batch-api/pull/183 saying no more than that the runtime must provide a JobOperator CDI Bean "if necessary".
I also added a new TCK test to inject JobOperator into an executing batch artifact (I didn't want to complicate the TCK by some other servlet or managed component type to the test).
However, Romain pointed out in comments:
https://github.com/eclipse-ee4j/batch-api/pull/183#issuecomment-991316256
https://github.com/eclipse-ee4j/batch-api/pull/183#pullrequestreview-828924368
that this could potentially break an existing user packaging their own JobOperator and suggested we might say something like "the runtime only adds a bean if it detects there is not already one present".
IMO, we should not detail the precedence or extension mechanism here.... but instead leave this up to vendors/implementations.
OTOH, I do not think we should remove the requirement altogether. I think the user should expect that a simple app can be deployed to a runtime that claims batch support and the runtime will have a JobOperator ready for it to inject.
OK, let me stop and hit send and see what everyone else thinks.
Thanks,
------------------------------------------------------
Scott Kurz
WebSphere / Open Liberty Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------