Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 61954 invoked from network); 21 Jan 2003 13:14:47 -0000 Received: from exchange.sun.com (192.18.33.10) by 208.185.179.12.available.above.net with SMTP; 21 Jan 2003 13:14:47 -0000 Received: (qmail 10569 invoked by uid 97); 21 Jan 2003 13:16:04 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 10527 invoked by uid 97); 21 Jan 2003 13:16:03 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 10515 invoked by uid 98); 21 Jan 2003 13:16:02 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <007401c2c14f$23324770$0a14a8c0@terre> From: "Chris Brown" To: "Tomcat Developers List" References: <3E2C2224.4010607@mail.more.net> <3E2C23A4.70901@joedog.org> Subject: Re: Why unpackWars=true default? Date: Tue, 21 Jan 2003 14:15:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N X-Spam-Rating: 208.185.179.12.available.above.net 1.6.2 0/1000/N > Would it be better to remove unpackWARs from tomcat5 since there isn't > that much of a concern for backwards compatibilty on major releases? > > -Tim It should always be at least an option to deploy WAR files without unpacking them. Systematically unpacking WARs would cause problems: the unpacked version is always used in preference to the packed version by Tomcat, so if unpackWARs="true", then overwriting the original ".war" file has no effect (because of the preference for using the directory if it exists), making upgrade deployment of webapps very problematic, leading to lots of support calls for us ("I replaced the WAR file, but nothing happens!"). It seems like a bad idea in many cases (obviously not all) to allow modifications within the webapp itself on production deployments (small sites and development releases of webapps are examples where this wouldn't always apply). All custom data in our apps is either stored in the user.home directory, the preferences API, JNDI, or whatever. We tend to consider the ".war" file like an ".exe" or executable JAR file. - Chris -- To unsubscribe, e-mail: For additional commands, e-mail: