I agree a job notification callback is useful. The deadline for final approval ballot is next week. The RI/TCK must be complete and in sync with the spec at the same time. Even a small addition to the spec at this point impacts RI and TCK. We are nearly out of time. We simply have to start saying no to good and useful, but otherwise non-essential, suggestions for improvement. But that doesn't mean people should stop commenting. We are close to having a v1.0 batch specification and we can bank suggestions for the next release.
Chris Vignola, STSM, IBM
JSR 352 Spec Lead
WebSphere Systems Management Architect
phone: 1+(720) 396-7501
email: " target="_blank">
Scott Kurz---03/13/2013 11:24:05 PM---Cheng, Thanks for considering this SPI and for your proposal.
From: Scott Kurz/Poughkeepsie/IBM@IBMUS
To: " target="_blank">
Date: 03/13/2013 11:24 PM
Subject: [jsr352-public] Re: JobExecution.awaitCompletion(long timeout)?
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.
Description: GIF image
[jsr352-public] Re: JobExecution.awaitCompletion(long timeout)?
Message not available
Message not available