[jira] [Commented] (IGNITE-15047) Support internal/private properties in configuration framework

["Ivan Bessonov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-15047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17408183#comment-17408183 ] 

Ivan Bessonov commented on IGNITE-15047:
----------------------------------------

[~ktkalenko@gridgain.com] looks good now, thank you for the contribution!

> 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
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: iep-55, ignite-3
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> 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)