Since the TCK SPI is a contract any implementor must meet to run the TCK, we definitely want to get it right and try to address your concerns.
Yes, it seems like you'd need at least the executionId to do the polling I'd suggested.
The JobOperator seems useful too and on quick review, I can't see a downside in requiring it be obtainable.
Thanks for giving this some more thought. Do you think then that those two methods would be sufficient?
WebSphere Batch / Compute Grid Development
External Phone 845-435-5649
Cheng Fang ---03/14/2013 11:00:26 PM---Thanks Scott for your thoughts and consideration. If we have to defer it to JSR 352.next due to ti
From: Cheng Fang < >
Date: 03/14/2013 11:00 PM
Subject: [jsr352-public] Re: JobExecution.awaitCompletion(long timeout)?
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.
Message not available
Message not available
[jsr352-public] Re: JobExecution.awaitCompletion(long timeout)?