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 highly readable. The interface is well-documented with clear Javadoc explaining its purpose and usage. The structure is logical, with method declarations and default implementations separated clearly. Nesting is non-existent, and each method has a single, clearly defined action. The reading flow follows a natural progression: interface declaration, main abstract method, then default methods. The only minor drawbacks are the long import statement and a slightly wrapped parameter description in the Javadoc, which slightly interrupts the visual flow. Overall, the code is concise, well-organized, and easy to understand.
Run 3
The interface is well-structured and highly readable. It clearly defines its purpose through comprehensive Javadoc, explaining the policy enforcement context, discovery mechanism, and usage. The code follows a logical organization, with a single method declaration preceded by descriptive documentation. Nesting is minimal, and each element—imports, annotations, method signatures—is clearly separated. Action granularity is excellent, with concise, single-purpose lines. Reading flow is natural: the class-level Javadoc sets context before method-level details. Code length is appropriate for an API contract, with no unnecessary repetition. Minor deductions are for the slightly long Javadoc block, which could be condensed, and the slightly verbose return description in the validate method. Overall, this is a clear, maintainable interface definition.
Run 1
Code Structure: The interface is logically organized, with a validation contract followed by simple default methods; import grouping and extra blank lines could be tidier. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy, validation behavior, and return contracts, though some documentation wording is awkward. Code length: The implementation is concise; documentation is longer but provides useful API context. Action granularity: Each declaration and return statement occupies its own line, with no compressed actions. Reading flow: The progression from interface overview to validation and defaults is natural. A misaligned Javadoc continuation and minor formatting inconsistencies slightly interrupt an otherwise clear presentation.
Run 2
Code Structure: A logically organized interface with imports, class documentation, and clearly separated methods. Nesting: Minimal nesting; default methods have simple, flat bodies. Clarity of intent: Descriptive names and detailed Javadoc make the policy's purpose and validation contract clear, though returning "undefined" for version provides little meaningful information. Code length: The implementation is concise; documentation is lengthy but mostly useful. Action granularity: Each declaration or return occupies its own line, with no bundled actions. Reading flow: Methods follow a natural progression from validation to configuration and version metadata. Minor formatting issues—extra blank lines, imports without grouping, and inconsistent Javadoc continuation indentation—slightly reduce polish.
Run 3
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 policy validation and default behavior, although returning "undefined" as the version provides limited information. Code length: The implementation is concise; documentation is somewhat verbose but mostly useful. Action granularity: Each statement performs a single action, with no compressed or compound operations. Reading flow: The progression from interface purpose to validation and metadata methods is natural. Minor formatting issues—extra blank lines, inconsistent Javadoc continuation indentation, and no separation between the package and imports—slightly reduce polish.