Thanks Scott for your thoughts and consideration. If we have to defer it to JSR 352.next due to time constraint, that's fine with me.
w.r.t. the TCK SPI, is it fully functional with a 3rd party implementation? The tck guide says 3 interfaces need to be implemented, but in the test class JobOperatorBridge, JobEndCallbackImpl is used directly. So looks like the tck user doens't need to implement this interface, and it has no role in how the tck spi impl connects to batch runtime.
However, JobEndCallback doesn't provide enough information and operations, with only 1 method done(long l). It is not sufficient to allow for various types of tck spi implementation, including the polling strategy you suggested. Can we add more to JobEndCallback, such as:
gJobOperator can be loaded by tck spi impl, but it would be easier if it is available from the callback object.
On 3/13/13 11:23 PM, Scott Kurz wrote:
Thanks for considering this SPI and for your proposal.
With our heads down in the TCK I'd been hoping others would raise the question of whether this was more generally useful or
if it were just a TCK-centric concern.
It is an onerous part of running the TCK against one's implementation that seems to call for a common solution.
Let me run by you a related thought I had here... this last issue, (your benefit #1), could be gained by simply implementing
JobEndCallbackManager with a piece of code that does polling. Further, this doesn't seem to me to be needed to complete
in the JSR timeframe... it could even be done later by someone running the TCK against something besides the RI (an important factor
since we're having this conversation with less than two weeks before our code freeze.
I realize you're arguing for it being part of the spec API.. just saying we don't need to add that just for the TCK. That wouldn't be off the
table completely in my mind, even given the time, since so many pieces are already in place.
The only caveat... like we did to the TCK with the loss of JobExecution's getInstanceId().. we might wrap our way out of it so as to make the change as quickly
as possible... even if that leaves the test methods themselves looking a bit atypical compared to "normal" API usage.
[jsr352-public] Re: JobExecution.awaitCompletion(long timeout)?
Message not available
Message not available