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... } } }
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.