Java Reference
In-Depth Information
Listing 10.3
A sample dao.xml with JDBC settings inserted with a <properties /> element
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE daoConfig
"-// DAO Configuration 2.0//EN"
<properties resource=""/>
<transactionManager type="JDBC">
<property name="DataSource" value="SIMPLE"/>
<property name="JDBC.Driver" value="${jdbcDriver}" />
<property name="JDBC.ConnectionURL"
value="${jdbcUrl}" />
<property name="JDBC.Username" value="${jdbcUser}" />
<property name="JDBC.Password"
value="${jdbcPassword}" />
<property name="JDBC.DefaultAutoCommit"
value="${jdbcAutoCommit}" />
<dao interface="..." implementation="..."/>
In this example, all of the property values are stored in a file named server.prop-
erties that is to be loaded from the root of the classpath.
This is an approach that we like to use, because all of the files can be kept
under version control, and the different versions of the properties files can be
named in a way that identifies them based on the environment (i.e., server-pro- , , etc.) so that the build procedure
can automatically copy the correct version to the correct location.
This approach also works well in more sensitive environments, where the con-
figuration settings are considered to be more secure by not having them under
version control. In those environments, it makes manual configuration simpler,
because the configuration file that changes based on the environment is always
the same file.
Multiple database dialects
If you are using the DAO pattern to support database platforms that are different
enough to require different code (i.e., using My SQL without stored procedures,
and Oracle with stored procedures), you can do something similar to the way we
performed earlier with the JDBC settings and make the package name part of the
properties file (see listing 10.4).
Search WWH ::

Custom Search