Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 45133 invoked from network); 22 Jan 2003 08:32:23 -0000 Received: from exchange.sun.com (192.18.33.10) by 208.185.179.12.available.above.net with SMTP; 22 Jan 2003 08:32:23 -0000 Received: (qmail 728 invoked by uid 97); 22 Jan 2003 08:33:46 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 687 invoked by uid 97); 22 Jan 2003 08:33:44 -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 632 invoked by uid 98); 22 Jan 2003 08:33:43 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <008701c2c1f0$d98be110$0a14a8c0@terre> From: "Chris Brown" To: "Tomcat Developers List" References: <20030122113102.C15259@zipperii.zip.com.au> Subject: Re: Why unpackWars=true default? Date: Wed, 22 Jan 2003 09:32:50 +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 To clarify, when I said I "consider" WARs as if they were EXEs, I mean that in many cases I think it's good practice to have a WAR file that doesn't try to modify itself internally (bit like having an EXE or whatever that modifies its contents or self-modifying assembler code...). Some webapps benefit from customisation, and are good candidates for unpacking, others are best left as a single unit which store environment settings externally. My main gripe with the unpackWARs setting is that if WARs are unpacked, it makes it more troublesome to upgrade, because a newer version of the WAR file is ignored if any previous version has already been unpacked (until the unpacked files are deleted). If the WAR file is updated, it's *probably* safe to assume that this was done voluntarily, and so any previous unpacked version should be removed then replaced. I don't really care if it's considered a deployment format or an executable format ; whether it's unpacked on disk, in memory, or whatever is irrelevant, as long as it works : it's up to the servlet engine to implement this as it wants (given that JSPs need to be compiled, obviously something needs to be created outside the WAR). Having said that, if we're meant to deploy as unpacked files, why bother with methods such as ServletContext.getResource() (when we could just use getRealPath if we systematically unpacked these files) ? - Chris ----- Original Message ----- From: To: "Tomcat Developers List" Sent: Wednesday, January 22, 2003 1:31 AM Subject: Re: Why unpackWars=true default? > On Tue, Jan 21, 2003 at 09:14:29AM -0500, Shapira, Yoav wrote: > > >consider the ".war" file like an ".exe" or executable JAR file. > > > > And I think this is where my interest comes from. Your considerations > > are exactly the opposite of Costin's (I think it was Costin anyways), > > who considers the .war file a *deployment* format only, like an RPM or a > > Windows Installer file, not to be run as an executable. > > I thought the raison d'etre of war's was acting like a single .exe. > > Or at least the default -- just as you're not expected to unpack jars. > > Matt -- To unsubscribe, e-mail: For additional commands, e-mail: