...

Replications are triggered in two ways: in bulk, via one of the org.sipfoundry.sipxconfig.service.ServiceConfigurator.replicateServiceConfig() overloaded methods or manually with the help of org.sipfoundry.sipxconfig.admin.commserver.SipxReplicationContext. In the first case all the configuration files of the service are replicated, in the second specific file replications are triggered. Ideally all files should be declared as configuration files that belong to a service and get replicated by the ServiceConfigurator.

Datasets replications

In addition to service configurations there is another type of replications: replication of datasets. TBD

...

In sipXconfig, services are registered as Spring beans in service.beans.xml. Here, amongst other properties, a list of "service configurations" is kept for each service.

...

  <bean id="sipxProxyConfiguration" class="org.sipfoundry.sipxconfig.service.SipxProxyConfiguration" scope="prototype"
    parent="serviceConfigurationFile">
    <property name="template" value="sipxproxy/sipXproxy-config.vm" />
    <property name="name" value="sipXproxy-config" />
    <property name="sipxServiceManager" ref="sipxServiceManager" />
  </bean>

  <bean id="peerIdentitiesConfiguration" class="org.sipfoundry.sipxconfig.service.PeerIdentitiesConfiguration" scope="prototype"
    parent="defaultConfigurationFile">
    <property name="name" value="peeridentities.xml"/>
    <property name="tlsPeerManager" ref="tlsPeerManager" />
    <property name="restartRequired" value="true" />
  </bean>

Datasets

org.sipfoundry.sipxconfig.admin.commserver.imdb.DataSet holds an enumeration of datasets. Dataset beans are registered in Spring in commserver.beans.xml. Here, the beans hold the configuration of the business beans that do the replication. These beans are implementations of org.sipfoundry.sipxconfig.admin.commserver.imdb.DataSetGenerator abstract class.

The other replications are configured similarly with the service configuration.

Lazy vs eager replication

...

...

Some operations may involve modifying a large chunk of entities, each of this modification triggering a replication. For instance, think about importing users from an LDAP server. Each save of a new user should be replicated in various configuration files. So, instead of doing a replication for each operation, the concept of lazy replication was introduced.

org.sipfoundry.sipxconfig.admin.commserver.LazySipxReplicationContextImpl is the implementation of the SipxReplicationContext that takes care of the lazy replications. Replication jobs are kept in an ArrayList of ReplicationTasks. A worker thread sleeps while waiting for something to be done and when there is, it is notified, sleeps for a bit and then it triggers the queued replications.

...

All configuration files extend the abstract class org.sipfoundry.sipxconfig.admin.AbstractConfigurationFile. org.sipfoundry.sipxconfig.admin.TemplateConfigurationFile is a Common common base class for all configuration files generators that use Velocity templating engine.

The service configuration files are a particular case of the TemplateConfigurationFile mentioned above. The configuration bean is registered in Spring as a child of serviceConfigurationFile bean. The class itself extends org.sipfoundry.sipxconfig.admin.TemplateConfigurationFile. Spring injects the sipxServiceManager into the bean. In the above example sipxProxyConfiguration is a serviceConfigurationFile. It uses sipXproxy-config.vm as the Velocity template. Of course other parameters can be configured on a case by case scenario.

Another common way to write XML files is to use org.dom4j.Document|http://dom4j.sourceforge.net/dom4j-1.6.1/apidocs/org/dom4j/Document.html. In the above example peerIdentitiesConfiguration is configured as a child of defaultConfigurationFile. The class itself extends org.sipfoundry.sipxconfig.admin.dialplan.config.XmlFile and it must override XmlFile.getDocument() method and return a dom4j document.

Other types of configuration files can be viewed by checking out the type hierarchy of org.sipfoundry.sipxconfig.admin.AbstractConfigurationFile.

isReplicable(Location location) and isRestartRequired()

The two are methods of the org.sipfoundry.sipxconfig.admin.ConfigurationFile interface.
From the javadoc, the method isReplicable(Location location) verifies if this configuration file can be replicated on the given location. The isRestartRequired() method checks if a service need to be restarted when this configuration file is changed.

...