> No, it doesn't. BTW, it's the responsibility of the container > to sweep the webapps folder, no?
I agree, so maybe it's a flaw in Tomcat that it's not doing this when running it via the <cactus> task? I normally just use <runservertests>, which works good enough, but I want to expand testing to Resin. Of course, it looks like this task doesn't support 3.0.x, so I might be wasting my time, eh? > But, yes, you're right, > there's currently no attribute in the <tomcat?x> nested > element to specify a custom context xml file. > > If you can point me to the doc explaining what context xml > files are, I should be able to add support for it quite > easily. What does it bring compared to server.xml? > It's basically a way to configure your Tomcat server w/o editing the server.xml. You can just drop your <Context> definition into an XML file and put it in the webapps directory. It's the same thing as putting a Context in server.xml. http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/context.html <quote> In addition to nesting Context elements inside a Host element, you can also store them in individual files (with a ".xml" extension) in the appBase directory for a Host. See Automatic Application Deployment for more information. </quote> Resin has the same ability, but you do have to tell it (in resin.conf) that you have a separate *.conf file. Sure would be nice if they'd pick that up automagically. Matt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
