[
https://issues.apache.org/jira/browse/IGNITE-15047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15047:
-----------------------------------
Description:
In order to provide consistent update of configuration and metastorage metadata
we should have configuration values that are hidden form the user.
Requirements are:
* these configuration values should be available from internal code only
* they should not be accessible in JSON or any other configuration view
representation
* they can't be updated via CLI's HOCON update requests or any other public
API calls
One possible solution is to have configuration schema extensions, registered in
"internal" modules - they'll lead to generation of extended VIEW and CHANGE
interfaces. All extra fields from these schemas will be marked as internal by
configuration framework, technically it is possible.
h3. API notes
I think it would be convenient to have explicit internal configuration
extensions like these:
{code:java}
@InternalConfigurationExtension
public class ExtendedConfigurationSchema extends PublicConfigurationSchema {
// fields
}{code}
There has to be some "extension descriptor", like a "RootKey", that should be
passed into configuration manager constructor (or registered in it by some
other means before component's start). It should have at least the information
about the schema that it extends.
Following restriction has to be applied:
* There cannot be multiple extensions for the same schema. It is possible to
avoid this restriction but it would lead to unnecessary complications (like in
polymorphic schemas, that would probably complicate such approach even more:
IGNITE-14645).
There's also no point in having extension in the same module. Maybe we should
validate this fact.
Every {{FooConfiguration}} object must in fact be an instance of
{{InternalFooConfiguration}} as well. Same applies to {{*View}} and {{*Change}}
interfaces. There's no way that it's possible to design API where its user
won't have to perform explicit type casts, so this solution looks fine.
h3. Implementation notes
First of all, annotation processor will be expanded. I suppose that
{{@InternalConfigurationExtension}} will be the only addition to public
configuration-api module, everything else will be hidden in implementation
packages.
Traversal / construction API will be expanded as well. I guess that adding a
{{internal}} flag to a bunch of method will be enough. Having two sets of
methods for {{all}} and {{public}} would just be too much.
After these methods are changed, {{ConfigurationAsmGenerator}} and a lot of
their usages will have to be fixed. I suspect that most changes will be here
and in tests.
was:
In order to provide consistent update of configuration and metastorage metadata
we should have configuration values that are hidden form the user.
Requirements are:
* these configuration values should be available from internal code only
* they should not be accessible in JSON or any other configuration view
representation
* they can't be updated via CLI's HOCON update requests or any other public
API calls
One possible solution is to have configuration schema extensions, registered in
"internal" modules - they'll lead to generation of extended VIEW and CHANGE
interfaces. All extra fields from these schemas will be marked as internal by
configuration framework, technically it is possible.
h3. API notes
> Support internal/private properties in configuration framework
> --------------------------------------------------------------
>
> Key: IGNITE-15047
> URL: https://issues.apache.org/jira/browse/IGNITE-15047
> Project: Ignite
> Issue Type: Task
> Reporter: Ivan Bessonov
> Priority: Major
> Labels: iep-55, ignite-3
>
> In order to provide consistent update of configuration and metastorage
> metadata we should have configuration values that are hidden form the user.
> Requirements are:
> * these configuration values should be available from internal code only
> * they should not be accessible in JSON or any other configuration view
> representation
> * they can't be updated via CLI's HOCON update requests or any other public
> API calls
> One possible solution is to have configuration schema extensions, registered
> in "internal" modules - they'll lead to generation of extended VIEW and
> CHANGE interfaces. All extra fields from these schemas will be marked as
> internal by configuration framework, technically it is possible.
> h3. API notes
> I think it would be convenient to have explicit internal configuration
> extensions like these:
> {code:java}
> @InternalConfigurationExtension
> public class ExtendedConfigurationSchema extends PublicConfigurationSchema {
> // fields
> }{code}
> There has to be some "extension descriptor", like a "RootKey", that should
> be passed into configuration manager constructor (or registered in it by some
> other means before component's start). It should have at least the
> information about the schema that it extends.
> Following restriction has to be applied:
> * There cannot be multiple extensions for the same schema. It is possible to
> avoid this restriction but it would lead to unnecessary complications (like
> in polymorphic schemas, that would probably complicate such approach even
> more: IGNITE-14645).
> There's also no point in having extension in the same module. Maybe we should
> validate this fact.
> Every {{FooConfiguration}} object must in fact be an instance of
> {{InternalFooConfiguration}} as well. Same applies to {{*View}} and
> {{*Change}} interfaces. There's no way that it's possible to design API where
> its user won't have to perform explicit type casts, so this solution looks
> fine.
> h3. Implementation notes
> First of all, annotation processor will be expanded. I suppose that
> {{@InternalConfigurationExtension}} will be the only addition to public
> configuration-api module, everything else will be hidden in implementation
> packages.
> Traversal / construction API will be expanded as well. I guess that adding a
> {{internal}} flag to a bunch of method will be enough. Having two sets of
> methods for {{all}} and {{public}} would just be too much.
> After these methods are changed, {{ConfigurationAsmGenerator}} and a lot of
> their usages will have to be fixed. I suspect that most changes will be here
> and in tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
