Advanced Caching Topics : Overriding and Extending the Operational Deployment Descriptor

Overriding and Extending the Operational Deployment Descriptor
The operational deployment descriptor is called tangosol-coherence.xml. This file is provided in BE_HOME/lib/ext/coherence.jar. In order to configure certain cache-related settings, you may need to override the values of certain elements in the operational deployment descriptor. This is explained in Overriding Element Values in Engine Property Files.
You may also need to define additional elements, and system properties for existing elements that lack them.
Overriding Element Values in Engine Property Files
TIBCO BusinessEvents overrides the values of elements in the operational descriptor using their system-property attributes. The system-property attribute values are used in Java command line options, and those options are included in some standard TIBCO BusinessEvents engine properties.
For example, the system-property attribute assigned to the element <cluster-name> is tangosol.coherence.cluster. TIBCO BusinessEvents uses this attribute to specify a value for <cluster-name> in the engine property (TRA) files as follows:
java.property.tangosol.coherence.cluster myclustername
System properties are predefined for many operational elements. You can override the value of any element that has a system-property attribute by adding a Java command line option in the engine property files, as shown in the example above.
For detailed documentation of this feature, and a list of elements for which system-property attributes are predefined, see the section "Line Setting Override Feature" in the online reference, TIBCO BusinessEvents Cache Configuration Guide.
Defining Additional Elements and System Properties in Override Files
If there is no system-property attribute for a setting you want to override, or if you need to add more elements than are available in the operational deployment descriptor, you must create an override file (or a series of override files) to contain the system-property attributes and any new elements you require. For example, you might add more elements to provide well-known addresses for the servers in a cache cluster.
You can store default values in an override file, and you can also create engine properties (using the system-property attributes) that override those file values. The settings you enter in engine property files override settings in the override file, and settings in the override file override those in the operational descriptor.
Override file elements that also exist in the operational descriptor must use the same structure as the elements in the operational descriptor.
Example: Adding Well Known Address Attributes
You would need to add elements if you use the well-known address method of defining a cache cluster and need more than six well-known addresses. (Six well-known addresses are declared in the default file, tangosol-coherence.xml.) Here is an example definition:

 
<well-known-addresses>
   <socket-address id="1">
      <address system-property="tangosol.coherence.wka"></address>
      <port system-property="tangosol.coherence.wka.port">8088</port>
   </socket-address>
</well-known-addresses>

 
In the override file, for example, tangosol-coherence-override-prod.xml, you add similar entries to the one provided in tangosol-coherence.xml, each specifying a unique system-property setting. For example:

 
<well-known-addresses>
   <socket-address id="7">
      <address system-property="tangosol.coherence.wka7"></address>
      <port system-property="tangosol.coherence.wka.port">8089</port>
   </socket-address>
   <socket-address id="8">
      <address system-property="tangosol.coherence.wka8"></address>
      <port system-property="tangosol.coherence.wka1.port">8089</port>
   </socket-address>
</well-known-addresses>

 
You can then use the system-property values in engine properties, and (in the case of the example shown) define the well known address values.