• Overview

• Profile Options

• Profile Config Source

• Profile Files

• Declarative

Configuration profiles provide a capability to prepare structure of configuration for each environment in advance, and then simply switch between these structures using a system property or an environment variable.

To choose a configuration profile to use at runtime, you can use:

1. A system property config.profile
2. An environment variable HELIDON_CONFIG_PROFILE

There are two ways to define a profile configuration:

1. Use a config source with a profile specific name
2. Use a profile file defining all configuration sources

Configuration profiles can only be used when config is created using the Config.create() method without parameters. If you explicitly configure sources, profiles are ignored.

If a profile is specified, config will load the profile-specific default configuration source before the "main" source.

Let’s consider the selected profile is dev, and we have yaml configuration support on classpath; config will look for the following sources (in this order):

1. application-dev.yaml on file system
2. application-dev.properties on file system
3. application-dev.yaml on classpath
4. application-dev.properties on classpath
5. application.yaml on file system
6. application.properties on file system
7. application.yaml on classpath
8. application.properties on classpath

If a profile is specified, config will look for a profile-specific "meta configuration".

Let’s consider the selected profile is dev, and we have yaml configuration support on classpath; config will look for the following profiles (in this order):

1. config-profile-dev.yaml on file system
2. config-profile-dev.properties on file system
3. config-profile-dev.yaml on classpath
4. config-profile-dev.properties on classpath

If any of these files is discovered, it would be used to set up the configuration. In case none is found, the config falls back to profile specific config sources.

The structure of the file is described below in profile file format.

In case you need to customize the location of the profile file, you can use the system property io.helidon.config.meta-config. For example if it is configured to config/profile.yaml, config looks for file config/profile-dev.yaml when dev profile is configured.

Profile File Format

sources:
  - type: "inlined"
    properties:
      app.greeting: "Hello World"

sources:
  - type: "environment-variables"
  - type: "system-properties"
  - type: "file"
    properties:
      path: "config/config-prod.yaml"
  - type: "classpath"
    properties:
      resource: "application.yaml"

caching.enabled: false
sources:
  - type: "system-properties"
  - type: "environment-variables"
  - type: "directory"
    properties:
      path: "conf/secrets"
      media-type-mapping:
        yaml: "application/x-yaml"
        password: "application/base64"
      polling-strategy:
        type: "regular"
        properties:
          interval: "PT15S"
  - type: "url"
    properties:
      url: "http://config-service/my-config"
      media-type: "application/hocon"
      optional: true
      retry-policy:
        type: "repeat"
        properties:
          retries: 3
  - type: "file"
    properties:
      optional: true
      path: "conf/env.yaml"
      change-watcher:
        type: "file"
        properties:
          delay-millis: 5000
  - type: "prefixed"
    properties:
      key: "app"
      type: "classpath"
      properties:
        resource: "app.conf"
  - type: "classpath"
    properties:
      resource: "application.conf"

public class MyConfigSourceProvider implements ConfigSourceProvider {
    private static final String TYPE = "my-type";

    @Override
    public boolean supports(String type) {
        return TYPE.equals(type);
    }

    @Override
    public ConfigSource create(String type, Config metaConfig) {
        // as we only support one in this implementation, we can just return it
        return MyConfigSource.create(metaConfig);
    }

    @Override
    public Set<String> supported() {
        return Set.of(TYPE);
    }
}

io.helidon.examples.MyConfigSourceProvider

sources:
  - type: "system-properties"
  - type: "environment-variables"
  - type: "my-type"
    properties:
        my-property: "some-value"

When using Helidon Declarative programming model (inversion of control, injection, annotation based), we may still be interested in the profile feature.

The interaction is as follows:

1. When config profile is defined, only sources from the profile are added (aligned with SE Imperative programming model)
2. When not using a config profile, ConfigSource services are discovered from the service registry, i.e. you can create a custom config source as a @Service.Singleton
3. If you want to have a config source that works both with a config profile, and with the default config instance, there is a solution (see below)
4. You can also define a ConfigSourceProvider as a registry service (and this will work the same as in SE imperative)

Designing a config source that integrates with profiles and default config

@Service.Singleton
@Service.Named(MyProfiledConfigSource.MY_TYPE)
public class MyProfiledConfigSource implements NodeConfigSource {
    static final String MY_TYPE = "my-config-type";

    private final String value;

    MyProfiledConfigSource(@Service.Named(MY_TYPE) Optional<MetaConfig> metaConfig) {
        this.value = metaConfig.flatMap(it -> it.metaConfiguration()
                        .get("app.value2")
                        .asString()
                        .asOptional())
                .orElse("meta-config-value-not-found");
    }

    @Override
    public Optional<ConfigContent.NodeContent> load() throws ConfigException {
        return Optional.of(ConfigContent.NodeContent.builder()
                                   .node(ConfigNode.ObjectNode.builder()
                                                 .addValue("app.value2", value)
                                                 .build())
                                   .build());
    }
}