jakarta-cactus-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Florin Vancea" <fvan...@maxiq.ro>
Subject Re: ant-integration and JBoss
Date Fri, 04 Jul 2003 16:33:13 GMT
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" <vmassol@pivolis.com>
To: "'Cactus Developers List'" <cactus-dev@jakarta.apache.org>
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:fvancea@maxiq.ro]
> > 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: cactus-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: cactus-dev-help@jakarta.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cactus-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: cactus-dev-help@jakarta.apache.org


Mime
View raw message