Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 54178 invoked from network); 5 Jul 2005 21:31:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Jul 2005 21:31:46 -0000 Received: (qmail 79574 invoked by uid 500); 5 Jul 2005 21:31:43 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 79483 invoked by uid 500); 5 Jul 2005 21:31:42 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 79470 invoked by uid 99); 5 Jul 2005 21:31:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jul 2005 14:31:42 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [211.29.132.199] (HELO mail18.syd.optusnet.com.au) (211.29.132.199) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 05 Jul 2005 14:31:42 -0700 Received: from [192.168.0.11] (c211-30-98-13.carlnfd1.nsw.optusnet.com.au [211.30.98.13]) (authenticated bits=0) by mail18.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j65LVajv010135; Wed, 6 Jul 2005 07:31:37 +1000 Message-ID: <42CAFBDD.3030802@optushome.com.au> Date: Wed, 06 Jul 2005 07:30:05 +1000 From: Andrew Franz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-au, en, en-us MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Running cocoon as a war archive References: <8b8d97d2050705133776f278f@mail.gmail.com> In-Reply-To: <8b8d97d2050705133776f278f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Irv Salisbury wrote: >I have always run cocoon as an expanded war directory. Our current >customer is requesting we run as a war file. Are there any resources >or problems people have found with this strategy? > >Thanks, > >Irv > > > > I had occasion to deal with an individual who insisted on this approach. It stems from a desire to 'lock down' production servers to prevent any changes. In practice, no software is perfect and there are times when a simple one-line change will immediately fix the problem. When you need to do this, you don't want to be making a one-line change in a staging environment and then re-deploying a 50Mb war file. Also you can't be totally certain that no other changes have been made in the staging environment. I would argue from a management perspective that deploying an expanded servlet is less risky and allows more responsive support. If the individual insists on the .war file approach, one possible approach is to run a staging servlet (expanded) in parallel with the production servlet (war file) - this has the advantage of the identical environment, available to test under production conditions & available as a backup in an emergency. On the technical level, there are issues with anything that needs to be written to, such as HSQLDB. See http://www.mail-archive.com/cocoon-users@xml.apache.org/msg07183.html Doesn't this belong in users@cocoon.apache.org?