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> validate(ConnectorClientConfigRequest connectorClientConfigRequest);
/**
* Configuration specification for this policy override.
*
* @return the configuration definition for this policy override; never null
*/
@Override
default ConfigDef config() {
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 version() {
return "undefined";
}
}
Run 1
The code is highly readable. Structure is logical, with clear package, imports, and interface definition. Nesting is nonexistent; methods are flat and concise. Intent is well-documented with Javadoc explaining purpose, usage, and discovery mechanism. Code length is appropriate for an interface with clear contracts. Each method signature is on one line, maintaining action granularity. Reading flow is natural, progressing from class-level docs to method declarations. Minor deductions: a Javadoc line slightly exceeds 80 characters and the return type description in the validate() method contains a line break, slightly disrupting flow. Overall, it exemplifies clean API design.
Run 2
The code is well-structured and highly readable. It consists of a single interface with clear purpose, documented thoroughly with Javadocs. Imports are organized, and the class hierarchy is simple. Nesting is virtually nonexistent, and each method has a single, clear intent. The code is concise despite comprehensive documentation, with no unnecessary logic or duplication. Action granularity is excellent—each relevant operation is isolated. The reading flow is natural: interface declaration, method signatures, and default methods follow a logical order. Minor deductions could be made due to slightly dense Javadoc comments, but overall this is exemplary readable code.
Run 3
The code is well-structured and readable. The interface has a single clear responsibility, and the method `validate` is concise. Javadoc comments are thorough but somewhat verbose, which slightly impacts reading flow. Nesting is minimal, and action granularity is appropriate. The use of default methods for `config()` and `version()` keeps the interface clean. Overall, the code is maintainable and understandable, with only minor verbosity in documentation.
Run 1
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method declarations. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadoc explain the policy's purpose, validation behavior, and return contracts. Code length: The implementation is concise, although documentation is somewhat verbose relative to the small interface. Action granularity: Each declaration and return statement occupies its own line, with no combined actions. Reading flow: Methods follow a natural order from validation to configuration and version metadata. Minor distractions include extra blank lines, ungrouped imports, long documentation lines, and a malformed Javadoc continuation line in the validate return description.
Run 2
Code Structure: The interface is logically organized, with imports, interface documentation, and clearly separated method declarations. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy, validation contract, and default methods. Code length: The implementation is concise, although extensive documentation and extra blank lines slightly reduce compactness. Action granularity: Each declaration and return occupies its own line, with no combined actions. Reading flow: The progression from interface purpose to validation and metadata methods is natural. Minor drawbacks include tightly packed imports, awkward wording in some documentation, and inconsistent indentation in the validate method's return documentation.
Run 3
Code Structure: A logically organized interface with imports, class documentation, and clearly separated method declarations. Nesting: Minimal; default methods contain only a single return statement. Clarity of intent: Descriptive names and detailed Javadoc explain validation, configuration, and version responsibilities. Code length: Implementation is concise, although documentation is somewhat verbose. Action granularity: Each executable statement occupies its own line. Reading flow: Natural progression from interface purpose to validation and default methods. Minor readability issues include extra blank lines, an inconsistently indented @return continuation, long documentation lines, and slightly awkward wording. These formatting issues do not significantly hinder understanding.