[jira] [Updated] (KAFKA-17001) Consider using another class to replace `AbstractConfig` to be class which always returns the up-to-date configs

["Kuan Po Tseng (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KAFKA-17001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kuan Po Tseng updated KAFKA-17001:
----------------------------------
    Summary: Consider using another class to replace `AbstractConfig` to be class which always returns the up-to-date configs  (was: Consider using another class to replace `AbstractConfig` to be class which alwasy returns the up-to-date configs)

> Consider using another class to replace `AbstractConfig` to be class which always returns the up-to-date configs
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-17001
>                 URL: https://issues.apache.org/jira/browse/KAFKA-17001
>             Project: Kafka
>          Issue Type: Improvement
>            Reporter: Chia-Ping Tsai
>            Assignee: Chia-Ping Tsai
>            Priority: Minor
>
> from https://github.com/apache/kafka/pull/16394#discussion_r1647321514
> We are starting to have separate config class ( i.e RemoteLogManagerConfig), and those configs will be initialized with a AbstractConfig. By calling `AbstractConfig' getters, those individual configs can always return the up-to-date configs. Behind the magic behavior is the instance of `AbstractConfig` ... yes, we use the `KafkaConfig` to construct those config classes. We call `KafkaConfig#updateCurrentConfig` to update inner configs, so those config classes which using `AbstractConfig` can see the latest configs too.
> However, this mechanism is not readable from `AbstractConfig`. Maybe we should add enough docs for it. Or we can move`KafkaConfig#updateCurrentConfig` into a new class with better naming.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)