Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 17394 invoked from network); 3 Sep 2008 16:58:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 3 Sep 2008 16:58:49 -0000 Received: (qmail 73107 invoked by uid 500); 3 Sep 2008 16:58:35 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 73083 invoked by uid 500); 3 Sep 2008 16:58:35 -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 73072 invoked by uid 99); 3 Sep 2008 16:58:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 09:58:35 -0700 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of dns4@cornell.edu designates 128.253.83.142 as permitted sender) Received: from [128.253.83.142] (HELO authusersmtp.mail.cornell.edu) (128.253.83.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Sep 2008 16:57:36 +0000 Received: from [128.253.209.217] (dns4-endeavour.calsnet.cornell.edu [128.253.209.217]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id m83GoaW2000471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 3 Sep 2008 12:50:37 -0400 (EDT) Message-ID: <48BEC05D.6040106@cornell.edu> Date: Wed, 03 Sep 2008 12:50:37 -0400 From: David Smith User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tomcat Users List Subject: Re: Problem with JNDI environment entry resources References: <0AAE5AB84B013E45A7B61CB66943C172142CEF7E3C@USEA-EXCH7.na.uis.unisys.com> <0AAE5AB84B013E45A7B61CB66943C172142CEF8434@USEA-EXCH7.na.uis.unisys.com> <48BEA346.8090507@cornell.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org I'm out then. I'm fine with the way tomcat operates and don't feel anything in the way context xml files are associated with webapps is ambiguous. It's really simple: 1. If you just want to deploy a webapp and don't need to define any resources like db pools, just drop the webapp in the webapps folder. The context xml file is not needed for such a basic deployment. The context path will be the name of the webapp. 2. If you need resources defined, then create a context xml file named after the webapp and placed in conf/EngineName/HostName. 3. Only define the docBase attribute of a ... element if your webapp live's outside the appBase of any of tomcat's ... definitions in server.xml. I'm sure if you'd like to make changes you could check out the tomcat source, make your changes, create a patch, and submit your proposal in Bugzilla for the tomcat committers to take a look at. If you feel the true problem is in the docs, patches are accepted for that as well. --David Paul Pepper wrote: > 2008/9/3 David Smith : > >> There's an implicit association based on the context path. myWebApp.xml in >> conf/Catalina/localhost is implicitly associated with the webapp myWebApp in >> the webapps directory, whether it be as a .war or expanded folder. >> > > Yes, I agree that the docs read this way. The point under discussion > here was the use of a docBase within server.xml - it's > necessary in order to disambiguate the use of a to a > specific application. > > >> Illegal may be a strong word -- it implies that tomcat will flat out reject >> the context when you define a docBase. If there is a docBase attribute >> defined, it may be ignored if there's a webapp in the webapps directory >> matching the context name (as defined by the *name* of the context xml file >> in conf/{Engine Name}/{Host name}, not the path attribute of > > > I don't understand "may be ignored". Either docBase is ignored in this > situation, or it isn't. > > >> ...>....). Worse, if the name of your webapp in webapps is >> different than the name of the context xml file in conf/{Engine Name}/{Host >> name}, you can get a double-deploy. Only one instance of the webapp will >> have the additional settings provided by the context xml file though. >> > > I'm afraid I haven't encountered this behaviour described in the docs. > I'd be grateful of a reference to it. Where documentation is missing, > or where further clarity is required (as suggested by repeated > user/developer mistakes), what is the procedure within Apache for > helping make this happen? > > >> Best practice overall is don't specify a docBase attribute unless your >> webapp is outside the appBase you are deploying the application to. Some >> people have reasons for doing this -- like when they absolutely have to have >> the war file named in some specific way that doesn't match the context path. >> > > That suggests that you've encountered cases where it is reasonable for > the docBase and the context's xml file name to differ. However, the > ambiguity in the use of docBase (re. above), and the double deployment > problem that you mention, makes it difficult to solve this problem - > worse if the use of taken away as an option. > > If it's agreeable to the guys that have responded so far, then I'd > like to get this discussion onto a thread of its own so that the > subject reflects the discussion and mail headers refer to a specific > topic. If you'd like to continue the discussion about that > we have started here, then please give me a little time to post this > question as another message on this list - referring to this thread in > the archives to avoid repetition. > > >> Also don't define a path attribute unless your ... >> element is in server.xml (absolutely NOT recommended). >> > > Agreed! > > Thanks, > > Paul. > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org