abhishekrb19 commented on code in PR #15485:
URL: https://github.com/apache/druid/pull/15485#discussion_r1422952440


##########
extensions-contrib/kafka-emitter/src/main/java/org/apache/druid/emitter/kafka/KafkaEmitterConfig.java:
##########
@@ -83,7 +87,8 @@ public KafkaEmitterConfig(
       @Nullable @JsonProperty("request.topic") String requestTopic,
       @Nullable @JsonProperty("segmentMetadata.topic") String 
segmentMetadataTopic,
       @JsonProperty("clusterName") String clusterName,
-      @JsonProperty("producer.config") @Nullable Map<String, String> 
kafkaProducerConfig
+      @JsonProperty("producer.config") @Nullable Map<String, String> 
kafkaProducerConfig,

Review Comment:
   What would happen if the type of existing `producer.config` is upgraded from 
`Map<String, String>` to `Map<String, Object>`? I _think_ the type upgrade 
should be safe considering `Object` is a superclass of `String`, but I'm not 
certain it would work seamlessly without breaking compatibility for existing 
deployments during rolling upgrades, rollbacks, etc.
   
   Alternatively, if the type upgrade approach isn't feasible, we could 
deprecate `producer.config Map<String, String>` in favor of a new config of 
type `Map<String, Object>` that encompasses the dynamic config provider similar 
to what you have here. This would be consistent with other areas of the system 
like [kafka consumer 
properties](https://github.com/apache/druid/blob/master/extensions-core/kafka-indexing-service/src/test/java/org/apache/druid/indexing/kafka/KafkaRecordSupplierTest.java#L718),
 [iceberg catalog 
properties](https://github.com/apache/druid/blob/master/extensions-contrib/druid-iceberg-extensions/src/main/java/org/apache/druid/iceberg/input/HiveIcebergCatalog.java#L78)
  since it's documented here: 
https://druid.apache.org/docs/latest/operations/dynamic-config-provider/



-- 
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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to