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 with clear structure and intent. It uses a standard interface declaration with well-organized imports, comprehensive Javadoc, and logical method grouping. Nesting is flat, with no conditional or loop complexity. Each method serves a single purpose, and action granularity is appropriate for an interface definition. The reading flow is natural, progressing from class-level documentation to method signatures and default implementations. Minor deductions: the validate() method's Javadoc has a slightly awkward line break in the return description, and there is a trailing blank line before the closing brace, but these are trivial issues. The code is concise yet informative, balancing brevity with necessary documentation.
Run 3
The code is highly readable, with a clear interface definition, well-structured Javadoc, and a logical flow. The import statements are concise and specific, and the class structure is organized with clear method separation. The nesting is minimal, with no deeply nested blocks. The intent of the interface is obvious from the class name and Javadoc, and each method has a single responsibility. Action granularity is appropriate, with one action per statement. The reading flow is natural, starting from package declaration, followed by imports, class Javadoc, interface declaration, and then methods. The only minor drawback is the slightly long return type in the Javadoc link, but overall the code is exemplary in terms of readability.
Run 1
Code Structure: The interface is logically organized, with imports, class 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, configuration, and version contracts. Code length: The implementation is concise, though the extensive documentation adds some verbosity. Action granularity: Each declaration and return statement occupies its own line, with no bundled actions. Reading flow: Methods follow a natural progression and documentation precedes each declaration. Minor distractions include extra blank lines, ungrouped imports, and inconsistent formatting in the multiline @return documentation.
Run 2
Code Structure: A well-organized interface with imports, class documentation, and clearly separated method declarations. Nesting: Minimal nesting, with only simple default method bodies. Clarity of intent: Descriptive names and detailed Javadoc clearly explain policy validation, configuration, and version reporting. Code length: The implementation is concise; documentation is somewhat lengthy but provides useful API context. Action granularity: Each statement occupies its own line, and each default method performs one straightforward action. Reading flow: The sequence from interface purpose to validation and plugin metadata is natural. Minor distractions include extra blank lines, inconsistent Javadoc continuation formatting, long documentation lines, and slightly awkward prose.
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 clearly explain the policy, validation behavior, and integration requirements. Code length: The implementation is concise, although documentation dominates and occasionally uses wordy phrasing. Action granularity: Each statement performs one action, with no combined operations. Reading flow: Natural progression from interface purpose to validation and plugin metadata methods. Minor distractions include extra blank lines, ungrouped imports, long documentation lines, and inconsistent indentation in the return documentation.