[
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:
----------------------------------------
[~ktkale...@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)
