This section describes the file structure of the master repository in STR, i e MZ_HOME/common/config/cell/default/master.

STR structure - Master repository

Files in the STR contains configurations that are represented in HOCON format.

Example - Pico configuration in STR

config {
	properties {
		ec {
			httpd {
				port=9090
			}
		}           
	}
}
template="mz.standard-ec"

HOCON also supports a "flat" format that you can use with properties, a type of attribute that you can set to control the behavior of pico instances in the STR :

config {
	properties {
		ec.httpd.port=9090           
	}
}
template="mz.standard-ec"

client.conf

The file client.conf contains custom default values for Desktop properties and JVM arguments. These values are set for all connected Desktop instances. You may override the default properties in the Desktop launcher.

config {
    jvmargs {
     . . .
    }
    properties {
     . . .
    }
}

default.conf

The file default.conf contains the installed default values for Desktop properties and JVM arguments. Though it is possible to edit this file, it is recommended that you add set custom default in in client.conf, since the contents may be overwritten by at any time.

config {
    jvmargs {
     . . .
    }
    properties {
     . . .
    }
}

cell.conf

The file cell.conf contains properties that are common to the Platform, EC/ECSAs and SCs.

common {
    config {
        name=common
    }
	#properties
}

custom.conf

The file custom.conf contains user defined service definitions.These definitions consist of a set of attributes that are required to run the services on one or more Service Contexts. Attributes that you set in custom.conf overrides attributes in standard.conf.

<service> {
 config {
  #properties...
 }
 start-after=[service1,...,service n]
 template="1/standard/basic"
}

standard.conf

The file standard.conf contains predefined service definitions that are required by the system. You can override the properties in this file by updating custom.conf.

<service> {
 config {
  #properties...
 }
 start-after=[service1,...,service n]
 template="1/standard/basic"
}

templates/<template name space>/picos/<template name>.conf

The files in the templates directory contains pico configuration templates. The subfolder mz contains preconfigured templates that should not be edited:

standard-ec
standard-ecsa
standard-sc
standard-platform
standard (base template for all pico types)

Note!

The name of the parent directory, e g mz, indicates a namespace that you must use when you reference the template in a pico configuration.

Though it is possible to edit these files, it is recommended that you add custom templates in separate files and subdirectories, since the contents in mz may be overwritten by at any time.

Example - Pico Configuration Template

config {
    properties {
        ec {
            backlog {
                dir=${mz.home}"/tmp"
            }
            httpd {
                password="DR_DEFAULT_KEY-1D2E6A059AF8120841E62C87CFDB3FF4"
                port=9090
                user=mzadmin
            }
            shutdown {
                time=60000
            }
        }
        pico {
            bootstrapclass="com.digitalroute.wf.pico.ECSAHTTPD"
            type=ec
        }
    }
}
template="mz.standard"
template-only=true
type=ec

<pico name>.conf

Each pico configuration is stored in a separate file with the suffix .conf, e g platform.conf or ec1.conf. The configuration includes template references, classpaths, JVM arguments, and properties. When you change these attributes in a configuration, the corresponding pico instance must be restarted. Properties that are set in <pico name>.conf override properties in container.conf and cell.conf.

A configuration may also include "settings" attributes. Unlike e g properties, this type of attribute may contain array values and changes do not require restart of pico instances.

File contents:

{
	template=<template name space>.<template file name>
	settings {
		pico-groups=[]
		state=enabled
	    tags=[]
	}
 	config {
  		classpath {
			#classpaths...
  		}
  		jvmargs {
			#jvmargs...
		}
		properties {
			#properties...
		}
 	}
}

You can set the attributes of the pico process directly and/or inherit the attributes of a template. Attributes that are set directly will override those that are inherited from a template.

Example - Usage of Pico Configuration Template

{
	template="example-ec"
	settings {	
		pico-groups=[group1]
		state=enabled
	    tags=[tag1,tag2] 
	}
	config {
		properties {
    		ec.httpd.port: 9090
   		}
  	}
}

container.conf

The file container.conf holds system properties and attributes that describe the container. Properties that are set in container.conf overrides properties in cell.conf.

Example - Container configuration

 
additional-addresses=[]
address="10.46.50.82"
common {
    #properties
    pico.rcp.server.host="" 
}
disabled=false

You can change the address attribute of the local container using the following command:

$ mzsh topo register -u --address <IP address or hostname>

If you want to prevent EC/ECSAs or SCs from starting in a container, set the attribute disabled to true. The default value is false.

$ mzsh topo set topo://container:<container>/val:disabled <true|false>

If the pico instances that run in the container should connect to the system from different addresses than the container address, you should add these to additional-addresses.

$ mzsh topo set topo://container:<container>/obj:additional-addresses \
[`mzsh topo get --format data-only topo://container:<container>/pico:<pico>/val: \
config.properties.pico.rcp.server.host`]

Example - Setting additional addresses

$ mzsh topo get --format data-only topo://container:main1/pico:ec1/val: \
config.properties.pico.rcp.server.host

"10.46.50.82"
 
$ mzsh topo set topo://container:main1/obj:additional-addresses ["10.46.50.82"]

As an alternative to adding additional addresses, you may set the platform property mz.pico.skip-registration-check. This allows the pico instances to connect from any address.

STR File Structure