[
https://issues.apache.org/jira/browse/KAFKA-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13699095#comment-13699095
]
Jay Kreps commented on KAFKA-943:
---------------------------------
Yeah, I think the core disagreement is that we are optimizing for slightly
different uses. I think the "right way" to handle config is through a config
management system external to the application--that is why we use properties to
begin with instead of just a config pojo--so I think that is the use case I am
optimizing for. In that case the property name *is* the contract. This has
obvious pros and cons. The pro is having a hard separation between config and
code and the ability to manage configuration at user-defined groupings (the
instance, server, cluster, datacenter, and fabric levels, say). The con is that
it is not compile time checked.
I agree that this is somewhat subjective.
The rationale for warning versus error for unused configs is the ability to
make configuration detached from the application. I.e. let's say you want to
roll out kafka client++ and it has a new configuration. Do you roll out the new
configuration first or the new code? If you do the config first then it is
important that we be able to ignore the property so that restarting your app
works, if it is the code then you will end up with the default which may or may
not work.
The non-existant properties are obviously embarrassing and we should fix them
irrespective of anything else.
> Move all configuration key string to constants
> ----------------------------------------------
>
> Key: KAFKA-943
> URL: https://issues.apache.org/jira/browse/KAFKA-943
> Project: Kafka
> Issue Type: Improvement
> Components: config
> Affects Versions: 0.8
> Reporter: Sam Meder
> Attachments: configConstants.patch
>
>
> The current code base has configuration key strings duplicated all over the
> place. They show up in the actual *Config classes, a lot of tests, command
> line utilities and other examples. This makes changes hard and error prone.
> DRY...
> The attached patch moves these configuration keys to constants and replaces
> their usage with a reference to the constant. It also cleans up a few old
> properties and a few misconfigured tests. I've admittedly not written a whole
> lot of Scala, so there may be some improvements that can be made, in
> particular I am not sure I chose the best strategy for keys needed by the
> SyncProducerConfigShared trait (or traits in general).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
