chia7712 commented on code in PR #19409: URL: https://github.com/apache/kafka/pull/19409#discussion_r2033591815
########## core/src/main/scala/kafka/server/KafkaConfig.scala: ########## @@ -194,16 +193,9 @@ class KafkaConfig private(doLog: Boolean, val props: util.Map[_, _]) private val _quorumConfig = new QuorumConfig(this) def quorumConfig: QuorumConfig = _quorumConfig - private val _groupCoordinatorConfig = new GroupCoordinatorConfig(this) Review Comment: I guess the drawback is to obstruct us from removing `KafkaConfig`. I'm thinking is it a good idea to have `KafkaConfig`-like class to contain all config objects, such as `GroupCoordinatorConfig` and `ShareCoordinatorConfig`. There are some benefits of keeping them here. 1. reduce the times of creating config objects. 2. have a center to access ALL config objects. However, the cost of creating config object should be cheap, and we can refactor code to avoid that as much as possible. Additionally, allowing `KafkaConfig` to return all other config objects is a anti-pattern to me, as it may cause a god object having a bunch of dependencies to other config classes. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
