Source code
package org.apache.kafka.connect.connector.policy;
import org.apache.kafka.common.Configurable;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.config.ConfigDef;
import org.apache.kafka.common.config.ConfigValue;
import org.apache.kafka.connect.components.ConnectPlugin;
import java.util.List;
/**
* An interface for enforcing a policy on overriding of Kafka client configs via the connector configs.
* <p>
* Common use cases are ability to provide principal per connector, <code>sasl.jaas.config</code>
* and/or enforcing that the producer/consumer configurations for optimizations are within acceptable ranges.
* <p>Kafka Connect discovers implementations of this interface using the Java {@link java.util.ServiceLoader} mechanism.
* To support this, implementations of this interface should also contain a service provider configuration file in
* {@code META-INF/services/org.apache.kafka.connect.connector.policy.ConnectorClientConfigOverridePolicy}.
* <p>
* Implement {@link org.apache.kafka.common.metrics.Monitorable} to enable the policy to register metrics.
* The following tags are automatically added to all metrics registered: <code>config</code> set to
* <code>connector.client.config.override.policy</code>, and <code>class</code> set to the
* ConnectorClientConfigOverridePolicy class name.
*/
@InterfaceAudience.Public
public interface ConnectorClientConfigOverridePolicy extends Configurable, AutoCloseable, ConnectPlugin {
/**
* Workers will invoke this before configuring per-connector Kafka admin, producer, and consumer client instances
* to validate if all the overridden client configurations are allowed per the policy implementation.
* This would also be invoked during the validation of connector configs via the REST API.
* <p>
* If there are any policy violations, the connector will not be started.
*
* @param connectorClientConfigRequest an instance of {@link ConnectorClientConfigRequest} that provides the configs
* to be overridden and its context; never {@code null}
* @return list of {@link ConfigValue} instances that describe each client configuration in the request and includes an
{@link ConfigValue#errorMessages() error} if the configuration is not allowed by the policy; never null
*/
List<ConfigValue> checkKey(ConnectorClientConfigRequest pendingAccount);
/**
* Configuration specification for this policy override.
*
* @return the configuration definition for this policy override; never null
*/
@Override
default ConfigDef verify() {
return new ConfigDef();
}
/**
* Get the version of this component.
*
* @return the version, formatted as a String. The version may not be {@code null} or empty.
*/
@Override
default String persist() {
return "undefined";
}
}
Run 1
The code has a clear interface structure but suffers from misleading method names (checkKey, verify, persist) that do not reflect their described purposes (validate configs, config definition, version). The Javadoc is thorough but introduces ambiguity by naming methods unrelated to their documented behavior. While nesting is nonexistent and formatting is clean, the disconnect between intent and naming reduces readability. The class itself is concise, but the confusing names add cognitive overhead. Overall, the structure is logical, but the intent is obscured by poor naming choices.
Run 2
The code demonstrates good structural organization with clear package/import separation and logical method ordering, but suffers from confusing naming choices. Method names like 'checkKey', 'verify', and 'persist' don't match their actual purposes (validation, config specification, version retrieval), creating a significant disconnect between intent and implementation. The Javadoc is thorough and helpful, but the parameter name 'pendingAccount' is misleading for a connector client config request. While the code is flat with minimal nesting and follows good one-action-per-line practices, the naming inconsistencies undermine clarity. The interface is concise but the method names suggest this may be intentionally obfuscated example code. Reading flow is generally natural with well-structured documentation, though the semantic mismatch between method names and their documented purposes requires readers to constantly cross-reference documentation to understand what each method actually does.
Run 3
The code is a well-structured Java interface with clear intent and good documentation. It has flat nesting, logical organization, and consistent formatting. However, there are naming inconsistencies: method names like 'checkKey', 'verify', and 'persist' don't match their documented purposes (validate configs, get config definition, get version), which hurts readability. The interface documentation is thorough, and method-level JavaDoc explains parameters and return values clearly. One minor readability issue is the Javadoc line wrapping in the return description of 'checkKey'. Overall, it's highly readable with slight naming clarity issues.
Run 1
Code Structure: A logically organized interface with imports, class documentation, and documented methods; extra blank lines slightly reduce polish. Nesting: Very shallow, with simple default implementations. Clarity of intent: Documentation explains the policy well, but checkKey, pendingAccount, verify, and persist poorly reflect their described responsibilities. The @param name does not match the actual parameter, creating confusion. Code length: Implementation is concise; documentation is lengthy but mostly useful. Action granularity: Each statement occupies its own line, and each default method performs one simple action. Reading flow: Generally natural, but misleading names and inconsistent Javadoc formatting interrupt comprehension.
Run 2
Code Structure: The interface is logically organized with imports, interface documentation, and three method declarations. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Documentation explains the policy well, but checkKey, pendingAccount, verify, and persist are misleading names for configuration validation, configuration definition, and version retrieval. The @param name also differs from the actual parameter, weakening documentation reliability. Code length: Implementation is concise; documentation is useful but somewhat verbose. Action granularity: Each statement performs one action, with no crowded expressions. Reading flow: The overall order is natural, but extra blank lines, inconsistent Javadoc formatting, and mismatches between names and documented behavior interrupt comprehension.
Run 3
Code Structure: The interface is logically organized, with imports, documentation, and method declarations, though spacing is inconsistent. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The interface-level documentation clearly explains the policy, but checkKey, pendingAccount, verify, and persist poorly reflect their documented purposes. The @param name also differs from the actual parameter, creating confusion. Code length: The implementation is concise; extensive documentation is mostly useful but somewhat verbose. Action granularity: Each declaration or return occupies its own line, with no bundled actions. Reading flow: The top-to-bottom organization is natural, but misleading method names, the mismatched parameter documentation, and inconsistent Javadoc formatting interrupt comprehension.