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/05/04 14:06:55 UTC
[GitHub] [ignite-3] sashapolo commented on a change in pull request #109: IGNITE-14657 README.md for ignite-configuration module.
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