Interface ConfigurationModule

All Known Implementing Classes:
ClientHandlerConfigurationModule

public interface ConfigurationModule
A module of configuration provided by a JAR file (or, in its source form, by a Maven/Gradle/... module).

Each configuration module only supplies configuration of only one ConfigurationType, so, if a library needs to provide both node-local and cluster-wide configuration, it needs to supply two ConfigurationModule instances.

Designed for integration with ServiceLoader mechanism, so ConfigurationModule instances provided by a library are to be defined as services either in META-INF/services/org.apache.ignite.configuration.ConfigurationModule, or in a module-info.java.

Supplies the following configuration components:

See Also:
  • Method Details

    • type

      Type of the configuration provided by this module.
      Returns:
      configuration type
    • rootKeys

      default Collection<RootKey<?,?,?>> rootKeys()
      Returns keys of configuration roots provided by this module.
      Returns:
      root keys
    • validators

      default Set<Validator<?,?>> validators()
      Returns configuration validators provided by this module.
      Returns:
      configuration validators
    • schemaExtensions

      default Collection<Class<?>> schemaExtensions()
      Returns classes of schema extensions (annotated with ConfigurationExtension) provided by this module, including internal extensions.
    • polymorphicSchemaExtensions

      default Collection<Class<?>> polymorphicSchemaExtensions()
      Returns classes of polymorphic schema extensions (annotated with PolymorphicConfig) provided by this module.
      Returns:
      polymorphic schema extensions' classes
    • patchConfigurationWithDynamicDefaults

      default void patchConfigurationWithDynamicDefaults(SuperRootChange rootChange)
      Patches the provided configuration with dynamic default values. This method is called
      • for cluster-wide configuration on cluster initialization.
      • for node-local configuration on the node start during the process of local configs reading.

      Dynamic defaults are default values that are not specified in the configuration source, but are added to the configuration on-the-fly, based on some external conditions.

      For example, if the configuration contains a list of caches, and the user specifies a list of caches in the source, then the defaults for the caches are not applied. But if the user does not specify a list of caches, then the configuration module may add a cache to the list based on some external conditions.

      The default implementation of this method is a no-op.

      Parameters:
      rootChange - Root change.
    • migrateDeprecatedConfigurations

      default void migrateDeprecatedConfigurations(SuperRootChange superRootChange)
      Logic to perform configuration migration when Ignite version is upgraded. Main task - replace deprecated configuration values with their non-deprecated cousins.

      Typical implementation should look something like this:

      
            var barValue = superRoot.viewRoot(KEY).foo().oldConfiguration().bar()
      
            if (barValue != BAR_DEFAULT) { // Usually implies explicitly set value.
                superRoot.changeRoot(KEY).changeNewFoo().changeBar(barValue)
            }
       
      Parameters:
      superRootChange - Super root change instance.
    • deletedPrefixes

      default Collection<String> deletedPrefixes()
      Returns a collection of prefixes, removed from configuration. Keys that match any of the prefixes in this collection will be deleted.

      Use ignite.my.deleted.property for regular deleted properties

      ignite.list.*.deletedProperty - for named list elements. Arbitrarily nested named lists are supported

      Returns:
      A collection of prefixes of deleted keys.