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 an interface with excellent readability. Structure is logical: package, imports, interface declaration, then methods in a natural order (validate, config, version). Nesting is nonexistent. Intent is clearly documented with comprehensive Javadoc explaining the purpose, use cases, and implementation requirements. The code is concise, containing only necessary methods with sensible default implementations. Each line performs a single logical action. Reading flow is natural—documentation precedes methods, and method ordering follows typical Java conventions. Minor deductions: the long Javadoc could be slightly condensed, and the @return doc for validate() has awkward line wrapping. Otherwise, it is nearly ideal as an API definition.
Run 3
The code is highly readable due to its clear structure: package declaration, imports, comprehensive Javadoc, and interface definition. Nesting is nonexistent (flat interface). The intent is unambiguous—the policy enforcement API is well-documented with examples and usage context. Code length is appropriate for a public interface with rich documentation. Action granularity is fine: each method or field is on its own line. Reading flow is natural: Javadoc precedes methods, and method order follows Java conventions (validate, config, version). Minor deductions: long Javadoc lines could be wrapped for narrower views, and the interface extends several types, which requires some navigation effort. Overall, near-exemplary readability.
Run 1
Code Structure: The interface is logically organized, with imports, interface documentation, validation, configuration, and version methods clearly separated. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadocs explain the policy purpose, validation behavior, and return contracts. Code length: The implementation is concise, although documentation dominates and contains some wordy phrasing. Action granularity: Each declaration and return statement occupies its own line, with no bundled actions. Reading flow: The progression from interface purpose to individual methods is natural. Minor readability issues include missing spacing between package and imports, extra blank lines before validate, and inconsistent indentation in the @return documentation.
Run 2
Code Structure: The interface is logically organized, with imports, interface documentation, validation contract, and default methods. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Descriptive names and detailed Javadoc clearly explain policy validation, discovery, and configuration; the default version value "undefined" is slightly less informative. Code length: The implementation is concise, though documentation is somewhat wordy and extra blank lines add minor clutter. Action granularity: Each declaration and return statement occupies its own line, with no bundled actions. Reading flow: Methods follow a natural sequence and consistent formatting overall, but tightly packed imports and inconsistent indentation in the return documentation slightly interrupt readability.
Run 3
Code Structure: Logically organized interface with validation followed by configuration and version defaults. Nesting: Minimal, with no nested control flow. Clarity of intent: Descriptive names and comprehensive Javadoc clearly explain the policy's purpose and validation contract. Code length: Implementation is concise; documentation is useful but somewhat verbose. Action granularity: Each declaration and return occupies its own line, making individual operations easy to identify. Reading flow: Natural progression from interface documentation to method contracts and implementations. Minor readability issues include excess blank lines, imports without grouping, long documentation lines, and inconsistent indentation in the @return continuation.