On Fri, Feb 6, 2009 at 12:45 PM, ant elder <[email protected]> wrote:
> > > On Thu, Feb 5, 2009 at 12:25 PM, Simon Laws <[email protected]>wrote: > > I switched calculator-rmi-sevice/buil.xml over to use this launcher and >>>> specify a timeout. A handy tactical fix. You'll see in >>>> itest/samples/build.xml that the rmi bit is commented out. The timeout >>>> seems >>>> to work but after the node is stopped the node launcher doesn't terminate. >>>> I >>>> expect we are holding some thread open somewhere. I don't think this has >>>> anything to do with the addition of the timeout but I don't have time to >>>> check it out just now. >>>> >>>> Simon >>>> >>> >>> Hmm. This means that users trying to run the sample with the "ant run" >>> target have the node shutdown after a few seconds and there is nothing they >>> can do about it! That seems quite far from ideal. (and on a side note isn't >>> the launcher timeout just duplicating function already available on the Ant >>> tasks?) >>> >>> Having itests to test the samples is really good but it needs to be >>> non-invasive, the primary purpose of the samples is to show users how to do >>> things as clearly as possible, if we can't get the itests working without >>> impacting the usability of the samples then i'd prefer we stay with the old >>> manual testing of the samples. Fortunately I think there will be ways we can >>> do the automated testing of this type of sample, perhaps using Ant timeouts, >>> IO Redirectors, or even a our own custom Ant task if necessary. >>> >>> ...ant >>> >>> Hi this was an outstanding TODO. I've changed the script so that the 4 >> second wait is only actiive when the script is run automatically. When run >> manually the time to live is 0 which mean wait for a key to be pressed. >> >> The propoer solution would of course be some kind of node management >> interface so we can ask it to stop explicitly. Not really high up the list >> at the moment though. >> >> Simon >> > > Doing this with a timeout still seems like a bit of a kludge to me, I'm > sure there must be a better way. Its fine as a work around for now but I'm > going to try to find a better way which doesn't involve having the sample > build scripts have to include any code for our integration testing. > > ...ant > > 1/ Correct me if I'm wrong but, while you didn't say so, I think you're agreeing with me. If not then maybe I don't understand what you mean. 2/ Give the code we have at the moment our scripts don't have any code in them which is explicitly for our integration tests. The script in question sets a timeout of 0 which, if the user were to look at it, would be quite instructive as that is what the launcher is doing for them, i.e. 0 timeout = wait til a key is pressed. I stress I'm not claiming this is a perfect solution. The better solution would be to have an mechanism whereby a node will stop when asked to do so. Simon
