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> val(ConnectorClientConfigRequest connector2);
/**
* Configuration specification for this policy override.
*
* @return the configuration definition for this policy override; never null
*/
@Override
default ConfigDef con() {
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 ver() {
return "undefined";
}
}
Run 1
The code has a clear top-level structure with an interface declaration and well-documented Javadoc comments that explain the purpose and usage. However, readability is notably reduced by several obfuscated method names: 'val', 'con', 'ver', and parameter 'connector2' lack clarity of intent. These abbreviations force the reader to rely on documentation rather than self-explanatory code. The interface itself is relatively flat with minimal nesting, and the code length is concise, but the overly verbose Javadoc comments somewhat increase length. Reading flow is natural in terms of overall organization, though the shortened names disrupt comprehension. Action granularity is appropriate with one action per declaration. Overall, the code would be significantly more readable with descriptive, conventional naming despite its otherwise solid structure and documentation.
Run 2
The code is a well-documented interface with clear Javadoc and a clean, flat structure. However, readability is significantly reduced by the use of truncated method names: 'val', 'con', and 'ver', and a parameter named 'connector2'. These non-descriptive names obscure intent and violate good naming conventions. The overall organization is logical, with appropriate imports and documentation. Nesting is minimal. The code length is reasonable, though some Javadoc comments are overly verbose. Action granularity is fine as methods are single-purpose. Reading flow is generally natural, but the abbreviated names break the flow, requiring readers to infer meaning from Javadoc rather than from the code itself.
Run 3
The code is highly readable. The interface has a clear, well-documented purpose with logical organization. Javadoc comments explain the contract and usage effectively. Nesting is flat—only interface and method declarations, no control flow. Methods and parameters have concise, meaningful names (e.g., 'val', 'con', 'ver', 'connector2'). Action granularity is clean; each line serves one purpose. Reading flow is natural, progressing from class purpose to method details. The only minor drawback is the slightly abbreviated parameter name 'connector2', which could be more descriptive, and method names like 'val' / 'con' require context but are acceptable within API conventions. Overall, it is structured, clear, and concise.
Run 1
Code Structure: The interface is logically organized, with imports, class documentation, and individual method contracts, though spacing is inconsistent. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Detailed documentation explains the policy's purpose, but abbreviated method names (val, con, ver) and the vague parameter name connector2 obscure intent. The @param documentation also names a nonexistent parameter, reducing trust in the contract. Code length: The implementation is concise, although documentation dominates the file. Action granularity: Each declaration or return occupies its own line, keeping individual actions clear. Reading flow: The top-to-bottom layout is natural, but dense documentation, uneven formatting, and mismatched names interrupt comprehension.
Run 2
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: Detailed documentation explains the policy's purpose, but abbreviated method names (val, con, ver) and the vague parameter name connector2 obscure intent. The @param documentation also names a nonexistent parameter, reducing reliability. Code length: The implementation is concise; documentation is lengthy but mostly useful, with some unnecessary whitespace. Action granularity: Each statement performs one action, and method bodies are simple. Reading flow: The top-to-bottom layout is natural, though inconsistent Javadoc formatting and the mismatch between descriptive documentation and cryptic identifiers interrupt comprehension.
Run 3
Code Structure: The interface is logically organized, with imports, class documentation, and clearly separated methods. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: Detailed documentation explains the policy's purpose, but abbreviated method names (val, con, ver) and the vague parameter name connector2 obscure intent. The @param documentation also names a nonexistent parameter, reducing reliability. Code length: The implementation is concise; documentation is lengthy but mostly useful. Action granularity: Each method performs a single action, with one statement per line. Reading flow: The declaration-to-method progression is natural, though extra blank lines, inconsistent Javadoc formatting, and the lack of spacing around import groups slightly disrupt presentation.