Projects:Share Openbravo properties/Technical Specifications

Contents 1 Overview 2 Approaches 2.1 background.policy 2.2 Other properties: file replacement 2.3 Other properties: overriding some properties 3 Naming the host 4 Development tasks 5 Final decision

Overview

When Openbravo is deployed in Tomcat clustering sharing physical files for all the webapps in each server, Openbravo.properties file is also shared. The target of this project is to define a mechanism to be able to have different values for some of these properties depending on the server.

The most common property to be modified is background.policy which allows to execute background processes in only one of the Tomcats in the cluster.

Approaches

background.policy

The most common property to be changed is background.policy which allows to define if background processes are executed or not in current server. Current design assumes each server has a different Openbravo.properties file, thus it is not possible to having a shared Openbravo.properties to allow to execute processes just in one of them.

To solve this problem it is possible to have a single Openbravo.properties file shared by all servers. We would add a new background policy (execute on host name) and a new property background.executeOnHost which value should be the name of the host to execute background processes in and would be only used if the policy is set to the new one. In this way only the host named like the new property value would execute background processes.

If the only different property is this one, this approach is preferred over the other one because it would only require to maintain a single Openbravo.properties file.

Other properties: file replacement

In case any other arbitrary property needs to be different between different Tomcats, the solution would be to have different files to define all of them, these files would be named as hostName.Openbravo.properties where hostName would identify each server in the cluster.

This approach would force to maintain all of these properties files.

Other properties: overriding some properties

Similar to previous approach, it would be possible hostName.Openbravo.properties file to define only the properties to override from the main Openbravo.properties file. In this manner main Openbravo.properties file would always be read and only the properties defined for that host in hostName.Openbravo.properties file would be overridden.

This approach covers the use cases defined for both previous approaches making easier to maintain host specific properties files as they only would have some of the properties.

Naming the host

For any of the both approach defined above it is necessary to be able to identify each of the hosts in the cluster.

• A way of getting host name might be java.net.InetAddress.getLocalHost().getHostName().
• If previous approach is not enough, it would be possible to set a jvm parameter naming the host.

Development tasks

Openbravo.properties is read at runtime from Openbravo running instance as well as from development tasks (ie. ant smartbuild). Node specific settings make only sense at runtime. When executing development tasks main Openbravo.properties files should always be used.

Final decision

After evaluating all the approaches the selected one is the partial override of only selected properties. Name of the instance can be defined by:

• New machine.name property in jvm (set ie. in CATALINA_OPTS).
• If that property is not set, java.net.InetAddress.getLocalHost().getHostName() is used.