...

Two or more configuration servers can be set up as a cluster, one running as a master and all others as slaves.

As above example shows, dispatcher 1 and web server 1 servers, are connected to config server 2, configured as a slave, and PTS server 1 and statistics server and config server 2 is connected to config server 1, where config server 1 is configured as a master.

...

<system name="Ceptor PortalProtect" version="6.0.0" copyright="(c) 2001-2017, Asseco Denmark">
	>
	<server name="configserver1" type="config" description="master config server" extends="configservers">
		<group name="cluster" description="cluster server configuration">
			<property name="cluster.server" value="master" valid="master|slave" description="valid values=&quot;master&quot; and &quot;slave&quot;"/>
			<property name="cluster.server.master" value="nios://localhost:21233?validateservercert=false" description="host and port of master server"/>
		</group>
		<group name="general" description="general configuration">
			<property name="list.log.directories" value="${portalprotect.home}/logs,PortalProtect Logs" description="List of log directories from which logfiles can be downloaded via the admin GUI"/>
			<property name="server.listenurls" value="local://21233;nios://21233" description="URLs to listen for connection"/>
			<property name="statistics.server" value="statisticsserver1" description="name of the statistics server"/>
			<property name="statistics.server.listenurls" value="local://21112" description="Listen URL for connection from statistics server"/>
		</group>
	</server>
	<server name="configservers" type="abstract" description="config servers shared configuration" extends="">
		<group name="consul" description="Consul Service lookup">
			<property name="consul.alloweduripattern" value="/v1/catalog/service/app*" description="Used to restrict which services an agent can lookup"/>
			<property name="consul.pollinterval" value="10" description="Cache lookups in consul for 10 seconds"/>
			<property name="consul.servers" value="" description="Consul servers to lookup services within - e.g. http://192.168.160.132:8500"/>
		</group>
		<group name="security" description="security configuration">
			<property name="access.control.configuration" value="${portalprotect.home}/config/portalprotect-security.xml" description="access control definitions"/>
			<property name="access.controller" value="dk.itp.security.accesscontrol.AccessControlListXMLImpl" description="config server access controller implementation"/>
			<property name="remote.servers" value="localhost,192.168.255.255,10.255.255.255" description="allowed remote servers, host:port separated by ,;"/>
		</group>
	</server>
</system>

...

In this example the maintenance team for x509 servers need only deliver XML snippets with name and listen address – the rest of the portal protect configuration file is provided for example by the PortalProtect administration team. The x509 maintenance team does not even need to know which abstract definition their servers are extending.

JSON Configuration

Some elements of Ceptor use configuration in JSON format - these properties are still stored within the XML file, but with names ending with _JSON_ - example:

<server name="apimanagement" type="abstract" description="Settings for API management" extends="">
  <group name="_JSON_" description="JSON configuration">
	<property name="apimanagement_JSON_" description="API management related configuration and metadata">
<![CDATA[{
  "environments": [
    {
      "name": "Sandbox",
    ....
}]]></property>
  </group>
</server

This naming convention is recognized by the console, which allows you to edit the JSON directly using a JSON editor with syntax hiliting.

Inheritance

Inheritance works differently for JSON that it does for regular properties. For regular properties, the value overrides any eventual value defined in a parent, but this does not make as much sense for JSON, where there is a need for more structure in the values.

By default, inheritance works in this way.

Given 2 server entries, parent and child, we start with the parents object, then for each top-level attribute in the child JSON it overrides the corresponding value in the parent with one exception - if the object is an array, the two elements are merged so the childs array contents are added to the parent.

Take this example:

{
  "key1": "a",
  "key2", "b",
  "key3": [
    "a",
    "b",
  ]
}

{
  "key1": "1",
  "key3": [
    "c"
  ],
  "key4": "d"
}

The result is then:

{
  "key1": "1",
  "key2", "b",
  "key3": [
    "a",
    "b",
    "c"
  ],
  "key4": "d"
}

But, it is also possible to change this behavior - if the child contains the array json.config.override  then the behavior changes and instead we start with the parent but then completely override the specified elements, adding any new elements - meaning the result becomes like this:

{
  "key1": "a",
  "key2", "b",
  "key3": [
    "a",
    "b",
  ]
}

{
  "config.override": [
    "key3"
  ],
  "key1": "1",
  "key3": [
    "c"
  ],
  "key4": "d"
}

The result is then:

{
  "key1": "a",
  "key2", "b",
  "key3": [
    "c"
  ],
  "key4": "d"
}

When json.config.override exists, the regular merging of arrays does not take place, and only keys specifically mentioned in the override array are replacing the corresponding elements in the parent.

You can find an example of this in the default distribution, where you have gateways as a parent, and gateway1  and gateway2  that as children each reuse the full configuration from the parent, except for the listener  settting which they optionally overrides.