[ https://issues.apache.org/jira/browse/KAFKA-3962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15468352#comment-15468352 ]
Shikhar Bhushan edited comment on KAFKA-3962 at 9/6/16 7:49 PM: ---------------------------------------------------------------- This is also realizable today by using {{ConfigDef.originalsWithPrefix()}}, if the template format is {{some.property.$resource}} rather than {{$resource.some.property}} as suggested above. There isn't library-level validation support when doing this, though. was (Author: shikhar): This is also realizable today by using {{ConfigDef.originalsWithPrefix()}}, if the template format is {{some.property.$resource}} rather than {{$resource.some.property}} as suggested above. There isn't framework-level validation support when doing this, though. > ConfigDef support for resource-specific configuration > ----------------------------------------------------- > > Key: KAFKA-3962 > URL: https://issues.apache.org/jira/browse/KAFKA-3962 > Project: Kafka > Issue Type: Improvement > Reporter: Shikhar Bhushan > > It often comes up with connectors that you want some piece of configuration > that should be overridable at the topic-level, table-level, etc. > The ConfigDef API should allow for defining these resource-overridable config > properties and we should have getter variants that accept a resource > argument, and return the more specific config value (falling back to the > default). > There are a couple of possible ways to allow for this: > 1. Support for map-style config properties "resource1:v1,resource2:v2". There > are escaping considerations to think through here. Also, how should the user > override fallback/default values -- perhaps {{*}} as a special resource? > 2. Templatized configs -- so you would define {{$resource.some.property}}. > The default value is more naturally overridable here, by the user setting > {{some.property}} without the {{$resource}} prefix. -- This message was sent by Atlassian JIRA (v6.3.4#6332)