Projects:Share Openbravo properties/Technical Specifications
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.
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 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
- If previous approach is not enough, it would be possible to set a jvm parameter naming the host.
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.
After evaluating all the approaches the selected one is the partial override of only selected properties. Name of the instance can be defined by:
machine.nameproperty in jvm (set ie. in
- If that property is not set,