You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ignite.apache.org by GitBox <gi...@apache.org> on 2021/04/27 09:15:48 UTC
[GitHub] [ignite-3] ibessonov opened a new pull request #109: IGNITE-14657 README.md for ignite-configuration module.
ibessonov opened a new pull request #109:
URL: https://github.com/apache/ignite-3/pull/109
Signed-off-by: ibessonov <be...@gmail.com>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite-3] sashapolo commented on a change in pull request #109: IGNITE-14657 README.md for ignite-configuration module.
Posted by GitBox <gi...@apache.org>.
sashapolo commented on a change in pull request #109:
URL: https://github.com/apache/ignite-3/pull/109#discussion_r623740551
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
+
+### Root Key
+
+`RootKey` interface represents a type-safe object that holds the _key_ of the root node. Instances of
+this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str = "foobar";
+
+ @Value
+ @Immutable
+ public String str;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`;
+ * All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+ to as a _key_. The `rootName` property assigns a _key_ to the root node of the tree that will represent
+ the corresponding configuration schema;
+* `@Config` is similar to the `@ConfigurationRoot` but represents an inner configuration node;
+* `@ConfigValue` marks a nested schema field. Cyclic dependencies are not allowed;
+* `@NamedConfigValue` is similar to `@ConfigValue` but such fields will basically become `Map<String, declared_schema>`;
Review comment:
> but such fields will basically become `Map<String, declared_schema>`;
This sentence makes little sense
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
+
+### Root Key
+
+`RootKey` interface represents a type-safe object that holds the _key_ of the root node. Instances of
+this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
Review comment:
Add an explanation about `NamedConfigValue` and `NamedLists`
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
Review comment:
Add more text here
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
+
+### Root Key
+
+`RootKey` interface represents a type-safe object that holds the _key_ of the root node. Instances of
+this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str = "foobar";
+
+ @Value
+ @Immutable
+ public String str;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`;
Review comment:
What is the `Vault` and `Metastorage` and what are the consequences of choosing one?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite-3] ibessonov merged pull request #109: IGNITE-14657 README.md for ignite-configuration module.
Posted by GitBox <gi...@apache.org>.
ibessonov merged pull request #109:
URL: https://github.com/apache/ignite-3/pull/109
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite-3] ibessonov commented on a change in pull request #109: IGNITE-14657 README.md for ignite-configuration module.
Posted by GitBox <gi...@apache.org>.
ibessonov commented on a change in pull request #109:
URL: https://github.com/apache/ignite-3/pull/109#discussion_r625708233
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
Review comment:
Done
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,157 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module.
+
+### Root Key
+
+`RootKey` interface represents a type-safe object that holds the _key_ of the root node. Instances of
+this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
Review comment:
Done
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite-3] alievmirza commented on a change in pull request #109: IGNITE-14657 README.md for ignite-configuration module.
Posted by GitBox <gi...@apache.org>.
alievmirza commented on a change in pull request #109:
URL: https://github.com/apache/ignite-3/pull/109#discussion_r622983626
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,142 @@
+# Configuration
+
+## Concepts
+This modules provides API classes and implementation for Ignite configuration framework. The idea is to have so called
+_Unified configuration_ - a common way of configuring both local Ignite node and Ignite clusters. Original concept can
+be seen in [IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+The core concept behind it is the _Configuration Schema_. It's required to generate public interfaces for the API and
+internal implementations that end user won't face. This way developers avoids writing boilerplate code.
+
+There are already meny examples throughout the code that looks somewhat like this:
Review comment:
many
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,142 @@
+# Configuration
+
+## Concepts
+This modules provides API classes and implementation for Ignite configuration framework. The idea is to have so called
+_Unified configuration_ - a common way of configuring both local Ignite node and Ignite clusters. Original concept can
+be seen in [IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+The core concept behind it is the _Configuration Schema_. It's required to generate public interfaces for the API and
+internal implementations that end user won't face. This way developers avoids writing boilerplate code.
+
+There are already meny examples throughout the code that looks somewhat like this:
+```
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value
+ public String str;
+}
+...
+```
+
+Main parts of what's present in this snippet are:
+* `@ConfigurationRoot` marks root schemas. In general, configuration consists of several things:
+ * property `type` shows that configuration can be either `LOCAL` or `DISTRIBUTED`. Main difference is that it'll be
+ stored in different _storages_ - `Vault` or `Metastorage`. But this information isn't known to configuration module,
+ only `ConfigurationStorage` interface is used. Other modules and tests just implement it and assign to corresponding
+ type constant.
+ * `rootName` gives this configuration a unique name. Basically all Ignite configuration is represented by a forest.
+ Every node in that forest has a name, usually referred to as a _key_. `rootName` assigns a _key_ to the root node of
+ the tree that will represent this particular configuration schema.
+* `@Config` has the same internal structure as `@ConfigurationRoot` but represents inner configuration node, not a root.
+ Things that it can have:
+ * `@ConfigValue` fields must be other schemas. Cyclic dependencies are not allowed.
+ * `@NamedConfigValue` fields must be other schemas as well. The main difference is that such fields will basically
+ become `Map<String, declared_schema>`.
+ * `@Value` fields must be of following types:
+ * `boolean` or `boolean[]`
+ * `int` or `int[]`
+ * `long` or `long[]`
+ * `double` or `double[]`
+ * `String` or `String[]`
+
+All _leaves_ **cannot be nulls**, that's a strict restriction for now. `@Value` fields might have following unique
+options:
+* `@Value(hasDefault = true)` - in this case schema field must be initialized in schema constructor. This initialized
+ value will be used as default if no value was provided by the user.
+* `@Immutable` - these properties cannot be changed once they are initialized either manually or with default value.
+
+Another important concept is a `RootKey`. It represents type-safe object that holds name of the root node. Instances of
+this interface are generated automatically and are mandatory for registering roots in the framework.
+
+`ConfigurationRegistry` is like a public facade of the module. It should be uses as an entry point for modules
Review comment:
used
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [ignite-3] sashapolo commented on a change in pull request #109: IGNITE-14657 README.md for ignite-configuration module.
Posted by GitBox <gi...@apache.org>.
sashapolo commented on a change in pull request #109:
URL: https://github.com/apache/ignite-3/pull/109#discussion_r625803832
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
Review comment:
```suggestion
This module contains the API classes and the implementation for the Ignite Configuration framework.
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
+
+### Root Key
+
+All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+to as a _key_. `RootKey` interface represents a type-safe object that holds the _key_ of the root node of the
+configuration tree.
+
+Instances of this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str1 = "foobar";
+
+ @Value
+ @Immutable
+ public String str2;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally while `Metastorage` is a distributed
Review comment:
```suggestion
to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally, while `Metastorage` is a distributed
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
+
+### Root Key
+
+All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+to as a _key_. `RootKey` interface represents a type-safe object that holds the _key_ of the root node of the
+configuration tree.
+
+Instances of this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str1 = "foobar";
+
+ @Value
+ @Immutable
+ public String str2;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally while `Metastorage` is a distributed
+ system that should store only cluster-wide configuration properties;
+ * `rootName` property assigns a _key_ to the root node of the tree that will represent
+ the corresponding configuration schema;
+* `@Config` is similar to the `@ConfigurationRoot` but represents an inner configuration node;
+* `@ConfigValue` marks a nested schema field. Cyclic dependencies are not allowed;
+* `@NamedConfigValue` is similar to `@ConfigValue` but such fields represent collection of properties, not a single
+ instance. Every element of the collection will have a `String` name, which makes it pretty much like a `Map`.
Review comment:
```suggestion
instance. Every element of the collection will have a `String` name, similar to a `Map`.
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
+
+### Root Key
+
+All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+to as a _key_. `RootKey` interface represents a type-safe object that holds the _key_ of the root node of the
+configuration tree.
+
+Instances of this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str1 = "foobar";
+
+ @Value
+ @Immutable
+ public String str2;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally while `Metastorage` is a distributed
+ system that should store only cluster-wide configuration properties;
+ * `rootName` property assigns a _key_ to the root node of the tree that will represent
+ the corresponding configuration schema;
+* `@Config` is similar to the `@ConfigurationRoot` but represents an inner configuration node;
+* `@ConfigValue` marks a nested schema field. Cyclic dependencies are not allowed;
+* `@NamedConfigValue` is similar to `@ConfigValue` but such fields represent collection of properties, not a single
+ instance. Every element of the collection will have a `String` name, which makes it pretty much like a `Map`.
+ `NamedListConfiguration` interface is used to represent this field in generated configuration classes.
+* `@Value` annotation marks the _leaf_ values. `hasDefault` property can be used to set default values for fields:
+ if set to `true`, the default value will be used to initialize the annotated configuration field in case no value
+ has been provided explicitly. This annotation can only be present on fields of the following types:
+ * `boolean` or `boolean[]`
+ * `int` or `int[]`
+ * `long` or `long[]`
+ * `double` or `double[]`
+ * `String` or `String[]`
+
+ All _leaves_ must be public and corresponding configuration values **can't be null**;
Review comment:
```suggestion
All _leaves_ must be public and corresponding configuration values **must not be null**;
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
Review comment:
```suggestion
The idea is to provide the so-called _Unified Configuration_ — a common way of configuring both local Ignite nodes
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
+
+### Root Key
+
+All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+to as a _key_. `RootKey` interface represents a type-safe object that holds the _key_ of the root node of the
+configuration tree.
+
+Instances of this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str1 = "foobar";
+
+ @Value
+ @Immutable
+ public String str2;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally while `Metastorage` is a distributed
+ system that should store only cluster-wide configuration properties;
+ * `rootName` property assigns a _key_ to the root node of the tree that will represent
+ the corresponding configuration schema;
+* `@Config` is similar to the `@ConfigurationRoot` but represents an inner configuration node;
+* `@ConfigValue` marks a nested schema field. Cyclic dependencies are not allowed;
+* `@NamedConfigValue` is similar to `@ConfigValue` but such fields represent collection of properties, not a single
Review comment:
```suggestion
* `@NamedConfigValue` is similar to `@ConfigValue`, but such fields represent a collection of properties, not a single
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
+
+### Root Key
+
+All Ignite configuration instances can be represented by a forest, where every node has a name, usually referred
+to as a _key_. `RootKey` interface represents a type-safe object that holds the _key_ of the root node of the
+configuration tree.
+
+Instances of this interface are generated automatically and are mandatory for registering the configuration roots.
+
+### Example Schema
+
+An example configuration schema may look like the following:
+
+```java
+@ConfigurationRoot(rootName = "root", type = ConfigurationType.LOCAL)
+public static class ParentConfigurationSchema {
+ @NamedConfigValue
+ private NamedElementConfigurationSchema elements;
+
+ @ConfigValue
+ private ChildConfigurationSchema child;
+}
+
+@Config
+public static class ChildConfigurationSchema {
+ @Value(hasDefault = true)
+ public String str1 = "foobar";
+
+ @Value
+ @Immutable
+ public String str2;
+}
+```
+
+* `@ConfigurationRoot` marks the root schema. It contains the following properties:
+ * `type` property, which can either be `LOCAL` or `DISTRIBUTED`. This property dictates the _storage_ type used
+ to persist the schema — `Vault` or `Metastorage`. `Vault` stores data locally while `Metastorage` is a distributed
+ system that should store only cluster-wide configuration properties;
+ * `rootName` property assigns a _key_ to the root node of the tree that will represent
+ the corresponding configuration schema;
+* `@Config` is similar to the `@ConfigurationRoot` but represents an inner configuration node;
+* `@ConfigValue` marks a nested schema field. Cyclic dependencies are not allowed;
+* `@NamedConfigValue` is similar to `@ConfigValue` but such fields represent collection of properties, not a single
+ instance. Every element of the collection will have a `String` name, which makes it pretty much like a `Map`.
+ `NamedListConfiguration` interface is used to represent this field in generated configuration classes.
Review comment:
```suggestion
`NamedListConfiguration` interface is used to represent this field in the generated configuration classes.
```
##########
File path: modules/configuration/README.md
##########
@@ -0,0 +1,163 @@
+# Configuration
+
+This module contains the API classes and the implementation for the Ignite configuration framework.
+The idea is to provide the so-called _Unified configuration_ — a common way of configuring both local Ignite nodes
+and remote Ignite clusters. The original concept is described in
+[IEP-55](https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration).
+
+## Concepts
+
+### Configuration Schema
+
+Type-safe schema of a configuration, which is used for generating public API interfaces and
+internal implementations to avoid writing boilerplate code.
+
+All schema classes must end with the `ConfigurationSchema` suffix.
+
+### Configuration Registry
+
+`ConfigurationRegistry` is the entry point of the module. It is used to register root keys, validators, storages and to
+start / stop component. Please refer to the class for more details.
Review comment:
```suggestion
start / stop the component. Refer to the class javadocs for more details.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org