Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 38188 invoked from network); 4 Apr 2000 20:47:44 -0000 Received: from adsl-63-198-47-229.dsl.snfc21.pacbell.net (HELO costin.dnt.ro) (63.198.47.229) by locus.apache.org with SMTP; 4 Apr 2000 20:47:44 -0000 Received: from eng.sun.com (costin [63.198.47.229]) by costin.dnt.ro (8.9.3+Sun/8.9.1) with ESMTP id NAA11850 for ; Tue, 4 Apr 2000 13:47:24 -0700 (PDT) Sender: costin@costin.dnt.ro Message-ID: <38EA4801.5B87AEA9@eng.sun.com> Date: Tue, 04 Apr 2000 12:52:33 -0700 From: Costin Manolache X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: tomcat-dev@jakarta.apache.org Subject: Re: WAR File problem - Don't cut final version until fixe References: <0007434F.C22202@seagram.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Jonathan Pierce wrote: > The directory is just a cache for the war file. If the war file timestamp has > changed, why not just delete the entire correcsponding directory and replace it > with the newly expanded contents of the new war file. We don't need to merge the > war file contents with the contents of the directory, just assume that if the > war file has changed since it was last expanded, then replace the entire > directory with its contents. Wrong - the directory is the _internal_ tomcat representation of a web application. The WAR file is the file format used for deployment. There is no cache for the war file - as soon as you deploy the web application, tomcat will use it's own internal representation. It was never intended to be a cache - and the "autoexpand" is just a helper and a cheap substitute for a real deployement tool. The current definition is: - deploy tool : cp file.war to webapps - un-deploy : rm -rf directory - update: un-deploy then deploy again And you have the option to edit the files in-place. At least that's what I implemented in tomcat. > I don't think we should put logic in the deploy tool if it isn't necessary since > people may want the option of using their own deploy tool that may not share the > same design. The deploy tool is dependent of the server - it has to take a WAR file as input and generate the server internal representation as output. For tomcat that means generate apache, iis and nes config files, create the right directory structure, etc. Any server is free to choose it's own internal representation, have it's onw directory structure, etc. The webapps/ directory is tomcat specific, and we tried to make "manual" deployment easy. When you upgrade an application you need to make a number of complex operations, like restarting Apache, generating config files, etc. It's not just "expand a war if changed". Costin