RivenSun2 commented on PR #12010:
URL: https://github.com/apache/kafka/pull/12010#issuecomment-1103997882
Hi @C0urante
Thank you for your review, and resubmitted the code changes again.
> What are your thoughts on retaining the validation for the sasl.mechanism
property, but only performing it when the property will actually be used? We
know that if SASL is enabled for the producer/consumer, then sasl.mechanism
cannot be null. Could we enforce this in a follow-up step in
ProducerConfig/ConsumerConfig after invoking the superclass constructor?
Because this verification logic is general, we can add a `public static`
method in `CommonClientConfigs`, which is called by the
`postProcessParsedConfig` method in
AdminClientConfig/ConsumerConfig/ProducerConfig.
```
public static void validateSaslMechanismConfig(AbstractConfig config) {
SecurityProtocol securityProtocol =
SecurityProtocol.forName(config.getString(CommonClientConfigs.SECURITY_PROTOCOL_CONFIG));
String clientSaslMechanism =
config.getString(SaslConfigs.SASL_MECHANISM);
if (securityProtocol == SecurityProtocol.SASL_PLAINTEXT ||
securityProtocol == SecurityProtocol.SASL_SSL) {
if (clientSaslMechanism == null ||
clientSaslMechanism.trim().isEmpty()) {
throw new ConfigException("When the " +
CommonClientConfigs.SECURITY_PROTOCOL_CONFIG + " configuration enables the SASL
mechanism, " +
SaslConfigs.SASL_MECHANISM + " configuration must be
non-null or non-empty string.");
}
}
}
```
But this change may require a KIP, we can put it in another PR to handle the
verification of this configuration `sasl.mechanism`, WDYT?
Thanks.
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
