They were even much-needed, since I had to hack the source and increase them substantially to get my Cactus+Maven+JBoss combination to work. Please see my recent post on JMX polling.
Florin ----- Original Message ----- From: "Vincent Massol" <[EMAIL PROTECTED]> To: "'Cactus Developers List'" <[EMAIL PROTECTED]> Sent: Tuesday, June 17, 2003 10:30 AM Subject: RE: ant-integration and JBoss > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
