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:
[email protected]
