Return-Path: 
 <users-return-167716-apmail-tomcat-users-archive=tomcat.apache.org@tomcat.apache.org>
Delivered-To: apmail-tomcat-users-archive@www.apache.org
Received: (qmail 54902 invoked from network); 16 Aug 2007 16:10:37 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 16 Aug 2007 16:10:37 -0000
Received: (qmail 99974 invoked by uid 500); 16 Aug 2007 16:10:22 -0000
Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org
Received: (qmail 99956 invoked by uid 500); 16 Aug 2007 16:10:22 -0000
Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@tomcat.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@tomcat.apache.org>
List-Post: <mailto:users@tomcat.apache.org>
List-Id: <users.tomcat.apache.org>
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Delivered-To: mailing list users@tomcat.apache.org
Received: (qmail 99942 invoked by uid 99); 16 Aug 2007 16:10:22 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2007 09:10:22 -0700
X-ASF-Spam-Status: No, hits=1.2 required=10.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: 128.253.83.142 is neither permitted
 nor denied by domain of dns4@cornell.edu)
Received: from [128.253.83.142] (HELO authusersmtp.mail.cornell.edu)
 (128.253.83.142)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2007 16:10:36 +0000
Received: from [128.253.38.244] (defiant.ento.cornell.edu [128.253.38.244])
	(authenticated bits=0)
	by authusersmtp.mail.cornell.edu (8.13.1/8.12.10) with ESMTP id
 l7GG9rlC006844
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <users@tomcat.apache.org>; Thu, 16 Aug 2007 12:09:54 -0400 (EDT)
Message-ID: <46C476D1.1060904@cornell.edu>
Date: Thu, 16 Aug 2007 12:09:53 -0400
From: David Smith <dns4@cornell.edu>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: JDBC driver of class '' for connect URL 'null' in Tomcat 5.5.12
References: <1187266683.46c4407bc4086@netmail.pipex.net>
  <46C4452A.60607@sra.com.au>
 <12d14fba0708160600l3c13ef74u4ca708f0d33e0b8@mail.gmail.com>
 <1187278028.46c46ccc33e5b@netmail.pipex.net> <46C47064.20504@cornell.edu>
 <46C47339.7050000@sra.com.au>
In-Reply-To: <46C47339.7050000@sra.com.au>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

In my experience, a resource is usually only relevant to one webapp.  
There's no need to put it in server.xml as a GlobalNamingResource unless 
you want that resource available in all your webapps.  Moving the 
resource to the <Context> block of a context.xml file also makes it so 
resources can come and go with deployment of an individual webapp 
without restarting tomcat and disrupting all the webapps.

Developers could define their Resources in the <GlobalNamingResources> 
... </GlobalNamingResources> block of server.xml and then add a 
<ResourceLink> element to the context.xml file.  That'll get you out of 
having database specific information in the <Context ..../> element.  
See this page for further details on that:

http://tomcat.apache.org/tomcat-5.5-doc/config/globalresources.html

--David

Matthew Kerle wrote:

> Hi David
>
> David Smith wrote:
>
>> My only editorial comment on the page is to NOT place your 
>> <Resource.../> or <Context .../> definition in server.xml as 
>> recommended on the page.  Place it in context.xml or myapp.xml as I 
>> describe above.
>
>
> Just quickly, I was wondering why you recommend this? I know the 
> tomcat docs have changed to reflect the deprecation of defining the 
> <Resource.../> or <Context .../> definition in server.xml, but I never 
> understood why, and personally doing things that way is a serious pain 
> for me since it means I need to build a separate deployment descriptor 
> for dev, test & prod, which means I need to know the prod database 
> details. which I don't want.
>
> Is there a better way that the sysadmin can setup a JNDI datasource so 
> that deployed war's don't have to contain database-specific details? 
> the only way I've seen so far is to configure that in the server.xml...
>
> cheers!
>


---------------------------------------------------------------------
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