I personally don't like timers at all... So I would +1 for the JMX polling stuff but -0 for exposing timeouts. The 500ms-1000ms are really internal stuff. They were just there to be on the safe side (not sure they were really needed or not). I'd rather remove them.
-Vincent > -----Original Message----- > From: Florin Vancea [mailto:[EMAIL PROTECTED] > Sent: 12 June 2003 11:14 > To: 'Cactus Developers List' > Subject: ant-integration and JBoss > > Hello all! > > I'm new here, please excuse me if I'm missing any local protocol rule. > > I just tried to use the ant-integration (through Maven's plugin) with > JBoss. > It's almost OK, but JBoss starts a little too slow and the first test > returns with 500-server error. > > I looked into it and here's what I found: > > Starting means telling the Container to start, then waiting for the > specified URL, then waiting some extra 1000ms (this is taken from > ContainerRunner, probably CVS HEAD). > > The problem is that JBoss starts the embedded Tomcat and this Tomcat may > even begin to serve some contexts (e.g. jmx-console), but the startup is > not > over "until the fat lady sings" :) > I guess that was the reason "startUpWait" was introduced in > ContainerRunner, > but 1000ms seems to be way not enough. > > However, currently there's no way to change this param (or at least I have > not found any obvious one in the source). > > It would be even hard to do that, since ContainerRunner is not backed by a > tag. > > I would suggest that startUpWait and shutDownWait should be moved into > AbstractContainer and added to the Container interface, too. Then, > ContainerRunner should use whatever "comes in" from the particular > Container > it got on creation. > This way one would be able to specify his particular "extra" timing on a > container-by-container basis. > It would be cool to go on a container basis, because different containers > might have different startup behaviors. I think one wouldn't want to set a > global value "good for all" and waste time on each testing cycle. > > I may even be able to provide a patch for that if I get some positive > feedback and nobody does the changes before two weeks from now (I'll be > travelling). > > Anyway, the increased timeout is only a short term solution. Maybe some > sort > of JMX checking for completion of the deployment would be the best > solution, > and I'm really-really contemplating doing that as well. > > Please tell me what do you think about that. > > Florin > > P.S. Vincent, as you see, I got on Cactus list anyway :) > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
