[ https://issues.apache.org/jira/browse/KAFKA-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13141517#comment-13141517 ]
Jay Kreps commented on KAFKA-181: --------------------------------- Yes, please yes. I recommend we create a Config object that wraps java.util.Properties. It should include all the random Utils helpers we have for parsing ints and stuff. Whenever a get() is called for a property string we should record that property in a set. We can add a method that intersects the requested properties with the provided properties to get unused properties. This config can be used in KafkaConfig and other configs. As a side note, there are many places where we need to be able let the user provide pluggins that implement an interface. Examples are the EventHandler and Serializer interfaces in the producer, and you could imagine us making other things such as offset storage pluggable. One requirement to make this work is that it needs to be possible for the user to set properties for their plugin. For example to create an AvroSerializer you need to be able to pass in a schema.registry.url parameter which needs to get passed through unmolested to the AvroSerializerImpl to use. To enable the config objects like KafkaConfig that parse out their options should retain the original Config instance. The general contract for pluggins should be that they must provide a constructor that takes a Config so that these configs can be passed through. > Log errors for unrecognized config options > ------------------------------------------ > > Key: KAFKA-181 > URL: https://issues.apache.org/jira/browse/KAFKA-181 > Project: Kafka > Issue Type: Improvement > Components: core > Reporter: Joel Koshy > Fix For: 0.8 > > > Currently, unrecognized config options are silently ignored. Notably, if a > config has a typo or if a deprecated config is used, then there is no warning > issued and defaults are assumed. One can argue that the broker or a consumer > or a producer with an unrecognized config option should not even be allowed > to start up especially if defaults are silently assumed, but it would be good > to at least log an error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira