ConfigHub overview

All configuration can be boiled down to key-value pairs (properties). Ignoring the format that surrounds various configuration components, configuration differences are always reduced to properties.

For example, in Development environment, a config file may contain a line like:

<Connector port="8080" redirectPort="8443"/>

While in Production the same line looks like this:

<Connector port="80" redirectPort="443"/>

Therefore, the merged configuration could be written as:

<Connector port="${ http.port }" redirectPort="${ http.redirect }"/>

And we have our two properties: http.port and http.redirect.

Context properties

In order to eliminate a mesh of configuration file and property duplication, ConfigHub changes the definition of a property. By assigning a context to a property value, a single property key can have multiple values, each with a unique context signature.

Note

Context Property

property = key: [ context_1: value, context_2: value, ... ]

When an application/client requests configuration, they only need to specify their context. Using a request context, the exact key-value pairing occurs, and the result is returned to the client.

Using example above, a request context Production would return:

http.port: 80
http.redirect: 443

While a request with context Development would return:

http.port: 8080
http.redirect: 8443

In this example, context is very simple - its composed with a single context hierarchy, Environment. However, context can be as complex as your environment demands - up to 10 context element hierarchy.

Context resolution

Context resolution is a process during which value-context of each key is compared to the request context in order to determine which properties should be returned.

Matching value to request context occurs in two steps:

1. Semantic Filter

For each context hierarchy, corresponding context-values from request and property are compared. For a match, corresponding context values have to satisfy following rules:

• If both are specified, they have to be the same;
• Either or both are a wildcard.

Example: Context-Request resolution

Assume a context property is defined with for a key logger.level with 4 values.

	Environment	Application	Instance
Request-Context	Production	WebServer	Webserver-Jim

Value-Context	*	*	Webserver-Jim	Match
Value-Context	Production	WebServer	*	Match
Value-Context	Production	*	*	Match
Value-Context	Development	*	*	No Match

The semantic filter has matched 3 values, and ignored a single value because Environment context hierarchy from Request-Context “Production” did not match “Development”.

2. Weight Filter

Weighted filter is only applied if Context-Request is fully-qualified (each context hierarchy is specified).

As repository’s context scope can vary in size (see Choosing Repository Context Scope), each of the context blocks is assigned specific weight. The widest scope specifications (left) carry less weight, while most specific parts (right) carry most weight.

For example, in a repository with 3 context hierarchies, weight is assigned as follows:

Environment [40] | Application [80] | Instance [160]

This repository might have a property defined with multiple values. Each value-context also has weight.

Example: Fully-Specified Request-Context resolution

	Environment	Application	Instance	Weight
Value-Context	*	*	Webserver-Jim	160	Match
Value-Context	Production	WebServer	*	40 + 80 = 120
Value-Context	Production	*	*	40

The value with the highest weight is matched, as it is the most relevant value for the given context request.

Here’s the ConfigHub property editor view of the same property - with the values expanded.