From users-return-240082-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org Sun Mar 3 19:56:10 2013 Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 787FDEAA1 for ; Sun, 3 Mar 2013 19:56:10 +0000 (UTC) Received: (qmail 7312 invoked by uid 500); 3 Mar 2013 19:56:07 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 7264 invoked by uid 500); 3 Mar 2013 19:56:07 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 7254 invoked by uid 99); 3 Mar 2013 19:56:07 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Mar 2013 19:56:07 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of james.mk.green@gmail.com designates 209.85.128.49 as permitted sender) Received: from [209.85.128.49] (HELO mail-qe0-f49.google.com) (209.85.128.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 03 Mar 2013 19:56:00 +0000 Received: by mail-qe0-f49.google.com with SMTP id 1so3388111qec.8 for ; Sun, 03 Mar 2013 11:55:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=o+pUgfgsMM2fc4UAu8JLJl1GYjnRp4q6DcYUnZR0FZQ=; b=wqWADiEv9VZWiHv7w09hucw2reGVhZXo/4TA1yQ1e9v7p70+gQlENDWwYasxXsThhi GYWIAoMx0aJwNbgztbBuAuRa7cZs6c2yHlS6/mJzwHR9LtuQQQt/XdFiIXllFxmZhkih E4TigcfwJ1b/En+y/r16c4oBhaDS8HPgDgWr2PwJ+yIAg8bbWPn7yWZ0QwyYDjTCR4Sd ia5lHewZg6dFWKHfD8nhQ5qucqQfiBmv1k8xqXxRcM3FBucXGXIyG7g/VMd2VKwU1y6r oFpbDKNnCiL0TtRNqXu3Tu6aApczF9lY4Cv0VvFGIuZCVDSAv605ggaNh7L73S50zIBo Q65g== MIME-Version: 1.0 X-Received: by 10.49.61.164 with SMTP id q4mr5804225qer.60.1362340539342; Sun, 03 Mar 2013 11:55:39 -0800 (PST) Received: by 10.49.35.204 with HTTP; Sun, 3 Mar 2013 11:55:39 -0800 (PST) In-Reply-To: <5133A821.9070808@apache.org> References: <51335EFB.4090003@apache.org> <51337187.1020906@apache.org> <51338F2A.4000104@apache.org> <5133A821.9070808@apache.org> Date: Sun, 3 Mar 2013 19:55:39 +0000 Message-ID: Subject: Re: Context.xml ignored. From: James Green To: Tomcat Users List Content-Type: multipart/alternative; boundary=047d7bd74da2e9232e04d70a9f9c X-Virus-Checked: Checked by ClamAV on apache.org --047d7bd74da2e9232e04d70a9f9c Content-Type: text/plain; charset=ISO-8859-1 On 3 March 2013 19:44, Mark Thomas wrote: > On 03/03/2013 19:25, James Green wrote: > > I am clearly inferring too much. An explicit statement would certainly > help > > reduce confusion, and perhaps cause the Netbeans people to avoid putting > > the path attribute into the context element - presumably they took the > view > > that it was supported? > > It was supported about 10 years and 4 major versions ago. > > > At this point may I ask what reason prevents you from supporting such a > > deployment facility? I am surprised that so much of what I would expect > is > > supported, yet this pretty significant part is not. I'm curious now as to > > why. > > The issue was that it lead to lots of problems when coupled with > automatic deployment. For example, if you have foo.war and bar.war in > your webapps directory and bar.war contains a context.xml file that > declares a path of "/foo" what happens? > > Now that is a relatively simple case where the desired behaviour could > be documented and Tomcat coded to implement it. However once all the > moving parts are taken into account: > - name of WAR file > - presence (or not) of context.xml with a path defined > - automatic deployment enabled (or not) > - context.xml file extracted to ${CATALINA_BASE}// > (or not) > - deployment of a new application that may (or may not conflict with > some of the above > - deployment order (context.xml, WAR, dir) > - detection of changes to context.xml and automatic re-deployment > - expansion (or not) of WAR file into corresponding directory > > it rapidly reached the point where the code was extremely fragile and > still had plenty of bugs. The decision was taken, therefore, to link the > base file name and context name as previously described. This removed > nearly all of the nasty edge cases, made for much simpler code and made > the overall process a lot easier to understand. > Fair enough. I appreciate the explanation - seems reasonable to me. > > > May I ask ask how deployment is usually carried out it development and > > project environments? Is it usually doing using the HTTP api (which is I > > presume the way Netbeans interacts with Tomcat)? > > Unlikely. I usually see the following process: > - stop the instance > - copy the WAR > - start the instance > I'll admit now to now having yet read any documentation on this - but is there a graceful shutdown procedure? Similar to apache2ctl graceful, but one that allows threads to complete naturally whilst preventing new inbound network connections to be accepted? I am of course thinking that such a stop/copy/start solution must be sat behind a proxy. > > I rarely see production deployments deploying via HTTP. YMMV. > > > Thanks again for your time. I would appreciate it if the documentation > > would clarify that the part of the webapp cannot be set within the > deployed > > webapp itself. > > I'm assuming s/part/path/ > Indeed. > > I'll take a look at that shortly. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org > For additional commands, e-mail: users-help@tomcat.apache.org > > --047d7bd74da2e9232e04d70a9f9c--