When processing the configuration file, Weave provides a couple of processing instructions that may help to make your life a little easier. They are include and set. These instructions provide a means to alter the configuration items before they are processed.
include
When the include processing instruction is used, the contents of the file specified are read and inserted into the configuration tree at the location where the include tag was specified.
<?xml version="1.0" encoding="UTF-8"?> <config xmlns="urn:com.cohga.server.config#1.0"... <?include client_main.xml?> </config>
the client_main.xml file could contain
<?xml version="1.0" encoding="UTF-8"?> <config xmlns="urn:com.cohga.server.config#1.0" xmlns:client="urn:com.cohga.html.client#1.0"> <client:config id="main"> <default>true</default> <debug>false</debug> <theme>grey</theme> ... </client:config> </config>
One other thing to note about that last example is that the included client_main.xml file uses two config tags, but these are different tags because they have different namespaces.
The include processing instruction can be particularly useful when moving a development configuration to a production server. The development and production servers can have a different version of the included file(s) but with the main configuration file remaining the same between the two systems.
It could also be used when repeated elements are required. For example, definitions of connection pools, and the same file used with multiple include instructions.
The name of the include file can be just the file name in which case the file is searched for in the same directory as the config.xml file However it could also be a fully qualified file name which specifies an exact location for the file or it can also reference a URL, allowing for the contents to be fetched from another server.
If the include reference points to a file then the system will also monitor the included files for changes.
set
The set instruction can supplement the include instruction by providing support for variable substitution within the configuration file.
A variation on the previous example can be used when only the hostname needs to change between the development and production servers, so this time config.xml could contain
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:com.cohga.server.config#1.0"...
<jdbc:dataSource id="datasource.main">
<driver>oracle.jdbc.driver.OracleDriver</driver>
<url><![CDATA[jdbc:oracle:thin:@${HOSTNAME}:1521:GIS]]></url>
<username>reader</username>
<password>0hn0w3rdun</password>
<pool:pool>
<maxActive>15</maxActive>
<minIdle>2</minIdle>
<maxIdle>2</maxIdle>
<testOnBorrow>true</testOnBorrow>
<timeBetweenEvictionRunsMillis>60000</timeBetweenEvictionRunsMillis>
<minEvictableIdleTimeMillis>1200000</minEvictableIdleTimeMillis>
<whenExhaustedAction>grow</whenExhaustedAction>
</pool:pool>
</jdbc:dataSource>
</config>
Then the datasource.xml file on the development server could contain
<?set HOSTNAME=development.example.com?>
and the datasource.xml file on the production server could contain
<?set HOSTNAME=production.example.com?>
The ${HOSTNAME} portion of config.xml would be replaced with the appropriate hostname. Also, note that the value substituted is taken verbatim as everything following the = up to the ?>, which includes white space and case is important.
Of course set can also be used to locate commonly referenced items in a single location at the start of the config.xml file to allow them to be easily changed later. For example passwords that are updated every month or defaults for functions such as connection timeouts.
Externally defined values
In addition to the set processing instruction, the value for a substitution variable can also come from system properties or from a property as defined during the startup of the Java Virtual Machine (JVM option). ${property_name} notation can then be used to substitute the values in place.