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 a well-structured Java interface with clear purpose, following standard conventions. It uses a flat hierarchy with no nested blocks, making it easy to follow. Each method and annotation is clearly separated, and the Javadoc is thorough, explaining behavior and usage. The action granularity is appropriate—one logical action per declaration or annotation. The reading flow is natural, moving from interface declaration to method definitions. Minor deductions: the long Javadoc on the interface could be slightly condensed, and the package/import section is slightly dense but still standard. Overall, highly readable.
Run 3
The code is highly readable with clear structure and purpose. The interface is logically organized, with a single method declaration and two default method implementations. Javadoc is thorough and explains intent well. Nesting is minimal (only imports/package at top level). However, there are a few minor issues: the @return tag for validate() has a line-break issue causing poor alignment, and the interface inherits from three parent interfaces which adds slight complexity. The code length is appropriate for a policy interface, and action granularity is fine—each method serves a single purpose. The reading flow is natural, though the long Javadoc slightly interrupts the interface declaration flow.
Run 1
Code Structure: The interface is logically organized, with imports, interface-level documentation, and clearly separated method declarations. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadocs clearly explain the policy's purpose, validation behavior, and return contracts. Code length: The implementation is concise; documentation is somewhat verbose but provides useful API context. Action granularity: Each statement performs a single action, and the default methods are straightforward. Reading flow: The progression from policy validation to configuration and version metadata is natural. Minor readability issues include missing separation between the package and imports, extra blank lines before validate, long documentation lines, and an improperly formatted Javadoc continuation line in the return description.
Run 2
Code Structure: A logically organized interface with imports, class documentation, and clearly separated method declarations. Nesting: Minimal nesting; default methods contain only simple returns. Clarity of intent: Descriptive names and detailed Javadoc explain policy validation, configuration, and version reporting. Code length: Implementation is concise, though documentation is somewhat verbose and extra blank lines add minor clutter. Action granularity: Each statement occupies its own line, with one action per default method. Reading flow: The progression from interface purpose to validation and supporting metadata is natural. Minor distractions include ungrouped imports, inconsistent Javadoc continuation formatting, and the slightly ambiguous default version string "undefined".
Run 3
Code Structure: The interface is logically organized, with imports, interface documentation, validation, configuration, and version methods. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadoc clearly explain the policy contract, lifecycle, and return values. 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. Reading flow: The progression from interface purpose to individual methods is natural. Minor readability issues include extra blank lines, inconsistent Javadoc continuation formatting, long documentation lines, and imports without grouping.