I've seen projects where the application code base contains database connection information - passwords and all, or, WAR files are rebuilt for each environment with properties substituted appropriately for the target environment.
Rather than putting database information in the application code, it makes more sense to use a JDNI data source provided by the container. This way the exact same application code is deployed to all environments, and we don't encounter any exposed passwords - since the owner of the container (in production environments the infrastructure/support team) define the data source themselves.
Database access via JNDI data source in Tomcat
In your application server you want to define a data source which points to the database server and schema of your choice. Here, I'm using the H2 database, and assuming this is the DEV Tomcat server, I point it to the DEV schema - define this resource in the Tomcat context.xml:
Your application server MUST have the database driver on its classpath, so you will want to add the appropriate driver jar to TOMCAT_HOME/lib.
Other containers such as GlassFish, WebLogic, WebSphere and JBoss will have equivalent ways of achieving this same configuration.
Now, in your application all you need to do is define the JNDI data source, which never changes:
Below are xml snippets of a Tomcat configuration which exposes some resources and a Spring application context file that uses those resources.
Rather than putting database information in the application code, it makes more sense to use a JDNI data source provided by the container. This way the exact same application code is deployed to all environments, and we don't encounter any exposed passwords - since the owner of the container (in production environments the infrastructure/support team) define the data source themselves.
Database access via JNDI data source in Tomcat
In your application server you want to define a data source which points to the database server and schema of your choice. Here, I'm using the H2 database, and assuming this is the DEV Tomcat server, I point it to the DEV schema - define this resource in the Tomcat context.xml:
<Resource name="jdbc/app1db" auth="Container" type="javax.sql.DataSource"In your TST, UAT, PRD servers you define similar data sources, pointing to the appropriate schemas, all with the same name.
maxActive="100" maxIdle="30" maxWait="10000"
username="sa" password="" driverClassName="org.h2.Driver"
url="jdbc:h2:tcp://devDbServer/~/dev"/>
Your application server MUST have the database driver on its classpath, so you will want to add the appropriate driver jar to TOMCAT_HOME/lib.
Other containers such as GlassFish, WebLogic, WebSphere and JBoss will have equivalent ways of achieving this same configuration.
Now, in your application all you need to do is define the JNDI data source, which never changes:
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName" value="java:comp/env/jdbc/app1db"/>
</bean>
With the database connection information encapsulated within the container, you don't need these details in the source code, you don't expose passwords to anyone and you don't need to repackage your application for each environment - deployment is simple.
Another similar use-case is for the mail server. You may also want to expose a String which could point to a properties file or server address - this can then be referenced in your spring application context.
Below are xml snippets of a Tomcat configuration which exposes some resources and a Spring application context file that uses those resources.
Posts
