> -----Original Message----- > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > Sent: 16 January 2004 16:12 > To: Cactus Users List > Subject: RE: cactus ant task on existing container ? > > Hi, > > may I ask a question about using the <generic> container ? > > It seems that when I would like to use an already running container, the > war-file that can be passed through the <cactus> task is ignored, or > better .. becomes useless. Using the predefined containers build a new > Tomcat container from scratch in a temporary directory, but does the > generic container do that also ? It seems not, at least I don't find the > temp dir (not in Document Settings/..).
You're right, it doesn't. It delegates this to your startup and shutdown elements (or startuptarget/shutdowntarget targets). > > Instead it tries to connect to an existing webapplication (the deployed > cactified testing war) given at the configured cactus port (e.g. 8080), > wich succeeds because I deployed the cactified war with Ant before running > the <cactus> task. You have the choice of deploying your app before the <cactus> task, or by implementing it in the startup phase inside the <cactus>/<generic> task. > > So it works, no problem there .. but what's the use of the 'warfile' > attribute in the <cactus> task when using the <generic> container ? You're right, the warfile (or earfile) attribute is ignored for the <generic> container. I guess in the future we could make it available through an Ant property so that you could use it in your start/stop scripts. -Vincent > > Regards, > Quinten > > -----Original Message----- > From: Quinten Verheyen > Sent: 14 January 2004 15:53 > To: Cactus Users List > Subject: RE: cactus ant task on existing container ? > > > Just to say thx Vincent for the advice about the generic container. > > It works ! After a day configuring, .. but the kick makes it all worth > wile :-) > > -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 14 January 2004 11:43 > To: 'Cactus Users List' > Subject: RE: cactus ant task on existing container ? > > > > > > -----Original Message----- > > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > > Sent: 14 January 2004 09:23 > > To: Cactus Users List > > Subject: RE: cactus ant task on existing container ? > > > > Hi Vincent, > > > > thank you for your very quick reply. > > > > Concerning the why and how : if a (tomcat) container is started with > lots > > of jar's (libraries ;-) ), property file configs, environment > variables > > etc. and runs about x different webapps, of wich most use common jars > (in > > this case given with the classpath env var when creating tomcat > service), > > I feel reluctant to put the same jar's in a new testing webapp lib > dir, > > reconfiguring properties, env vars, etc. > > Of course, I guess it should pose no problems, but I would like to > "reuse" > > things instead, instead of recreating/assigning them. What better way > to > > do it (in that case anyway) then just deploy the cactified war in that > > container (like I did with the browser method) ? > > Or am I totally on the wrong thinking path here .. (wich is very > possible > > considering my newbee score on the subject :D). > > I think the only thing not reused is the content of the tomcat conf/ > directory. All the rest is reused (libraries, etc). > > > > > Anyway, I'll put your advise about the <generic> container into > practice > > right away ! > > > > Thx :-) > > -Vincent > > > > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: 13 January 2004 17:56 > > To: 'Cactus Users List' > > Subject: RE: cactus ant task on existing container ? > > > > > > Hi Quinten, > > > > The <cactus> task automates the creation of a new container (as you > > rightly said). Some nested <container> elements support passing custom > > config file (the <jboss3x> one even supports passing a custom > container > > config). > > > > The <tomcat?x> containers only support passing a custom server.xml > file > > (through the use of the serverxml attribute). However it does not > > support specifying a full existing tomcat configuration). Actually we > > have not had the need yet... Passing server.xml has been enough for > all > > cactus users need so far. > > > > You mention other libraries. You mean jars right? These will be reused > > just fine. I don't see the problem. Are you modifying something else? > > > > OTOH if you wish to use your complete own tomcat config, you'll need > to > > use the <generic> container (see > > http://jakarta.apache.org/cactus/integration/ant/task_cactus.html). > > > > Thanks > > -Vincent > > > > > -----Original Message----- > > > From: Quinten Verheyen [mailto:[EMAIL PROTECTED] > > > Sent: 13 January 2004 17:45 > > > To: [EMAIL PROTECTED] > > > Subject: cactus ant task on existing container ? > > > > > > Hi, > > > > > > I'm confused about using the cactus ant task with an existing > > container > > > configuration. > > > > > > A tomcat container is running on my machine with a different webapps > > dir > > > instead of the standard webapps dir in the tomcat root. > > > > > > When running test cases I started first with building a cactified > war > > that > > > would then be deployed on the webapps dir of that container. Then my > > test > > > cases were run via the browser method, everything worked fine. > > > > > > When I want to automate the process via the ant task, I am puzzled > .. > > > > > > The way I understand it, using the <cactus> task installs a new > Tomcat > > > container with possibly minimum config to a temp dir. > > > > > > But, .. I need to run the tests on the existing tomcat container, > not > > on a > > > new one ! It is running several other libraries that have nothing to > > do > > > with my test cases, but they are used by the classes that are > tested. > > > Objects that are in memory, etc. > > > > > > So, is there a way to automatically run cactus unit tests on an > > existing > > > container (like I did with the non-automatic browser method) ? > > > > > > Thx in advance.. > > > > > > --------------------------------------------------------------------- > > 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] > > > --------------------------------------------------------------------- > 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]
