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]
