I prefer a third approach that takes the best from Approach 1 and Approach 2 described by user1016403.

Approach 3

1. Save database properties on the server.xml
2. reference the server.xml database properties from the web application META-INF/context.xml

Approach 3 benefits

While the first point is useful for security reasons the second point is useful for referencing server properties value from the web application, even if server properties values will change.

Moreover decoupling resource definitions on the server from their use by the web application makes such configuration scalable across organizations with various complexity where different teams work on different tiers/layers: the server administrators team can work without conflicting with developers team if the administrator shares the same JNDI name with the developer for each resource.

Approach 3 implementation

Define the JNDI name jdbc/ApplicationContext_DatabaseName.

Declare the jdbc/ApplicationContext_DatabaseName's various properties and values in Tomcat's server.xml using something like this:

<GlobalNamingResources>  <Resource name="jdbc/ApplicationContext_DatabaseName" auth="Container" type="javax.sql.DataSource"              username="dbUsername" password="dbPasswd"              url="jdbc:postgresql://localhost/dbname"              driverClassName="org.postgresql.Driver"              initialSize="5" maxWait="5000"              maxActive="120" maxIdle="5"              validationQuery="select 1"              poolPreparedStatements="true"/></GlobalNamingResources/>

Link the jdbc/ApplicationContext_DatabaseName's properties from web application META-INF/context.xml by an application-private JNDI context java:comp/env/ specified in the name attribute:

<Context path="/ApplicationContext" ... >  <!--    "global" attribute links to GlobalNamingResources in the ${catalina.base}/conf/server.xml (server administrator team)    "name" attribute is relative to the application-private JNDI context java:comp/env/ and is looked up from the java web application (application developer team)  -->  <ResourceLink global="jdbc/ApplicationContext_DatabaseName" name="jdbc/DatabaseName" type="javax.sql.DataSource"/></Context>

Finally, in order to use the JNDI resource, specify the JNDI name jdbc/DatabaseName in web application's deployment descriptor:

<resource-ref>    <description>DatabaseName's Datasource</description>    <res-ref-name>jdbc/DatabaseName</res-ref-name>    <res-type>javax.sql.DataSource</res-type>    <res-auth>Container</res-auth></resource-ref> 

and in Spring context:

<jee:jndi-lookup id="DatabaseNameDataSource"   jndi-name="jdbc/DatabaseName"   expected-type="javax.sql.DataSource" />

Approach 3 drawbacks

If the JNDI name gets changed then both the server.xml and the META-INF/context.xml will have to be edited and a deploy would be necessary; nevertheless this scenario is rare.

Approach 3 variations

Many data sources used by one web application

Simply add configurations to Tomcat's server.xml:

<GlobalNamingResources>  <Resource name="jdbc/ApplicationContext_DatabaseName1" ... />  <Resource name="jdbc/ApplicationContext_DatabaseName2" ... />  ...</GlobalNamingResources/>

Add link web application META-INF/context.xml by an application-private JNDI context java:comp/env/ specified in the name attribute:

<Context path="/ApplicationContext" ... >  <ResourceLink global="jdbc/ApplicationContext_DatabaseName1" name="jdbc/DatabaseName1" ... />  <ResourceLink global="jdbc/ApplicationContext_DatabaseName2" name="jdbc/DatabaseName2" ... />  ...</Context>

Finally add JNDI resources usage in web application's deployment descriptor:

<resource-ref>    <description>DatabaseName1's Datasource</description>    <res-ref-name>jdbc/DatabaseName1</res-ref-name> ... </resource-ref> <resource-ref>    <description>DatabaseName2's Datasource</description>    <res-ref-name>jdbc/DatabaseName2</res-ref-name> ... </resource-ref>...

and in Spring context:

<jee:jndi-lookup id="DatabaseName1DataSource"   jndi-name="jdbc/DatabaseName1" ... /><jee:jndi-lookup id="DatabaseName2DataSource"   jndi-name="jdbc/DatabaseName2" ... />...

Many data sources used by many web application on the same server

Simply add configuration to Tomcat's server.xml:

<GlobalNamingResources>  <Resource name="jdbc/ApplicationContextX_DatabaseName1" ... />  <Resource name="jdbc/ApplicationContextX_DatabaseName2" ... />  <Resource name="jdbc/ApplicationContextY_DatabaseName1" ... />  <Resource name="jdbc/ApplicationContextY_DatabaseName2" ... />  ...</GlobalNamingResources/>

the others configuration should be deducible from previous variation case.

Many data sources to the same database used by many web application on the same server

In such case a Tomcat's server.xml configurations like:

<GlobalNamingResources>  <Resource name="jdbc/ApplicationContextX_DatabaseName" ... />  <Resource name="jdbc/ApplicationContextY_DatabaseName" ... />

ends up in two different web applications META-INF/context.xml like:

<Context path="/ApplicationContextX" ... >  <ResourceLink global="jdbc/ApplicationContextX_DatabaseName" name="jdbc/DatabaseName" ... /></Context>

and like:

<Context path="/ApplicationContextY" ... >  <ResourceLink global="jdbc/ApplicationContextY_DatabaseName" name="jdbc/DatabaseName" ... /></Context>

so someone might be worried about the fact that the same name="jdbc/DatabaseName" is looked up, and then used, by two different applications deployed on the same server: this is not a problem because the jdbc/DatabaseName is an application-private JNDI context java:comp/env/, so ApplicationContextX by using java:comp/env/ can't (by design) look up the resource linked to global="jdbc/ApplicationContextY_DatabaseName".

Of course if you felt more relaxed without this worry you might use a different naming strategy like:

<Context path="/ApplicationContextX" ... >  <ResourceLink global="jdbc/ApplicationContextX_DatabaseName" name="jdbc/applicationXprivateDatabaseName" ... /></Context>

and like:

<Context path="/ApplicationContextY" ... >  <ResourceLink global="jdbc/ApplicationContextY_DatabaseName" name="jdbc/applicationYprivateDatabaseName" ... /></Context>

YOUR_APP.xml file

I prefer Approach 2 (put everything (not only some attribute in the config), but instead of placing them in the global server.xml or global context.xml you should place it in the application-specific context.xml.default YOUR_APP.xml file in your Tomcat.

The YOUR_APP.xml file is located in $catalinaHome/conf/<engine>/<host> (for example conf/Catalina/localhost/YOUR_APP.xml).

The configuration in application specific YOUR_APP.xml is only available for the specific application.

See the guide published by MuleSoft. And see the official documentation, Tomcat Configuration Reference, page for The Context Container

• Version 9
• Version 8

To quote that documentation:

Individual Context elements may be explicitly defined:

• …

• In individual files (with a ".xml" extension) in the $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. The context path and version will be derived from the base name of the file (the file name less the .xml extension).

• …

Approach 4

Instead of using JNDI I work with .properties files and build complex object during program initialization instead on configuration time.

You already use Spring and it is easy construct DataSource by:

<context:property-placeholder location="classpath:app.properties"/><bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">    <property name="driverClassName" value="oracle.jdbc.OracleDriver"/>    <property name="url" value="jdbc:oracle:thin:@${db.host}:${db.port}:${db.user}"/>    <property name="username" value="${db.user}"/>    <property name="password" value="${db.pass}"/></bean>

I completely agree with Ralph with using deployment descriptor in $CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xmlbut instead JNDI I like plain key-value file!

With Spring injecting above properties into bean fields are easy:

@Value("${db.user}") String defaultSchema;

instead of JNDI:

@Inject ApplicationContext context;Enviroment env = context.getEnvironment();String defaultSchema = env.getProperty("db.user");

Note also that EL allow this (default values and deep recursive substitution):

@Value('${db.user:testdb}') private String dbUserName;<property name='username' value='${db.user.${env}}'/>

To externalize .properties file I use modern Tomcat 7 that has org.apache.catalina.loader.VirtualWebappLoader:

<Loader className="org.apache.catalina.loader.VirtualWebappLoader"        virtualClasspath="/srv/web/app/"/>

So your devops fill virtualClasspath with local external full paths which is separate per application and put local app.propertiesto that dir.

See also:

• Adding a directory to tomcat classpath
• Can I create a custom classpath on a per application basis in Tomcat
• Externalizing Tomcat webapp config from .war file
• How to read a properties file outside my webapp context in Tomcat
• Configure Tomcat to use properties file to load DB connection information
• Externalize Tomcat configuration