[
https://issues.apache.org/jira/browse/IGNITE-19294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-19294:
-----------------------------------
Description:
Сurrently, the configuration root can only be modified and extended in the
module where the configuration root is defined. Let's describe the situation.
Module *A* -> configuration root *Root1*
Module *B* depends on module {*}A{*}. In some cases, module *B* wants to extend
the *Root1* configuration with additional staff, but this is currently not
possible. This limitation looks artificial and there are cases when this
extension is necessary and in the current architecture we have to create a
separate root for each module, which, from the point of view of configuration
semantics, may look quite strange for the user.
h3. Example
We have a *security* module with the configuration
{code}
security {
authentication {
enabled=false
}
} {code}
Imagine we want to add one more authentication component that is located in
another module that depends on *security*.
If this module had its own properties to configure, the only way to do that is
to add a new configuration root.
Instead we want to mix-in the properties into the *security* tree.
The combined configuration root will look as follows:
{code}
security {
authentication {
enabled=false
type=plain
}
user="admin"
} {code}
h3. Proposed slution
Ignite already supports extensions, but only for its internal purposes and does
not expose the extended configurations to the users.
We can reuse this functionality by converting it to a full-featured extensions
with an option to control whether they are internal or public.
was:
Сurrently, the configuration root can only be modified and extended in the
module where the configuration root is defined. Let's describe the situation.
Module *A* -> configuration root *Root1*
Module *B* depends on module {*}A{*}. In some cases, module *B* wants to extend
the *Root1* configuration with additional staff, but this is currently not
possible. This limitation looks artificial and there are cases when this
extension is necessary and in the current architecture we have to create a
separate root for each module, which, from the point of view of configuration
semantics, may look quite strange for the user.
> Support merged configuration roots for multiple modules
> -------------------------------------------------------
>
> Key: IGNITE-19294
> URL: https://issues.apache.org/jira/browse/IGNITE-19294
> Project: Ignite
> Issue Type: New Feature
> Reporter: Mikhail Pochatkin
> Assignee: Kirill Sizov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Сurrently, the configuration root can only be modified and extended in the
> module where the configuration root is defined. Let's describe the situation.
> Module *A* -> configuration root *Root1*
> Module *B* depends on module {*}A{*}. In some cases, module *B* wants to
> extend the *Root1* configuration with additional staff, but this is currently
> not possible. This limitation looks artificial and there are cases when this
> extension is necessary and in the current architecture we have to create a
> separate root for each module, which, from the point of view of configuration
> semantics, may look quite strange for the user.
> h3. Example
> We have a *security* module with the configuration
> {code}
> security {
> authentication {
> enabled=false
> }
> } {code}
> Imagine we want to add one more authentication component that is located in
> another module that depends on *security*.
> If this module had its own properties to configure, the only way to do that
> is to add a new configuration root.
> Instead we want to mix-in the properties into the *security* tree.
> The combined configuration root will look as follows:
> {code}
> security {
> authentication {
> enabled=false
> type=plain
> }
> user="admin"
> } {code}
> h3. Proposed slution
> Ignite already supports extensions, but only for its internal purposes and
> does not expose the extended configurations to the users.
> We can reuse this functionality by converting it to a full-featured
> extensions with an option to control whether they are internal or public.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
