Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 22090 invoked from network); 2 Jan 2002 22:28:29 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Jan 2002 22:28:29 -0000 Received: (qmail 15630 invoked by uid 97); 2 Jan 2002 22:28:12 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 15613 invoked by uid 97); 2 Jan 2002 22:28:11 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 15602 invoked from network); 2 Jan 2002 22:28:11 -0000 Subject: Tomcat 4.0.1, explicit context, bug 4829? To: tomcat-user@jakarta.apache.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: steve_olson@illinoispower.com Date: Wed, 2 Jan 2002 16:28:02 -0600 X-MIMETrack: Serialize by Router on DECNTNMAIL1/DECSRV/Dynegy(Release 5.0.8 |June 18, 2001) at 01/02/2002 04:28:10 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I think I'm hitting the situation described in bug 4829, and wanted to confirm and see if anyone knows more status than what's in bugzilla. I also wasn't sure whether this should be a tomact-dev post instead. War files in the webapps directory expand fine at startup when the underlying subdirectory does not exist and Tomcat is using the DefaultContext stuff in server.xml. However, with Tomcat stopped, if the underlying subdirectory is deleted, and a Context entry for the war is added to server.xml, and Tomcat is restarted, the war does not get expanded (even though the owning Host in server.xml has unpackWARs="true"). The context runs fine directly from the war. Here's specifics: WAR name is Cis.war, deployed in CATALINA_HOME\webapps. server.xml has these lines added: The doc and a couple of the bug reports indicate that this is known behavior covered by 4829 and a couple of its dups. 4829 is REOPENED status, does anyone know if this behavior is planned to be changed and if so what the proposed behavior is? I'd also be interested in what others think the behavior oughta be... For us the current behavior is fine for production deploys where we don't typically care too much if the war is expanded because we do release-based pushes of changes anyway. But in a development environment it is nice to be able to copy over individual classes/web resources from time to time, and still redploy a new war from time to time too, all without having to tweak server.xml. Thanks in advance for any info... -- To unsubscribe: For additional commands: Troubles with the list: