[
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