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() {
{
int previousNumber = 0;
int currentNumber = 1;
for (int sequenceStep = 0; sequenceStep < 4; sequenceStep++) {
int nextNumber = previousNumber + currentNumber;
previousNumber = currentNumber;
currentNumber = nextNumber;
}
}
return "undefined";
}
}
Run 1
The code is a Kafka Connect policy interface. While the Javadocs and interface structure are reasonably clear, a significant error destroys readability: the version() method contains an unrelated Fibonacci sequence code block inserted into the middle of the method. This violates multiple criteria. The action granularity is poor because the version method attempts to mix irrelevant operations. The clarity of intent is severely compromised—why is Fibonacci logic in a version getter? Reading flow is disorganized, jumping from policy validation docs to unrelated numerical code and back. Nesting is not the primary issue, but the structure is broken by this misplaced block. Code length is also impacted negatively. Additionally, the Javadoc for validate() has a formatting inconsistency in the @return line. Overall, while the interface itself is standard, the glaring insertion of unrelated logic and formatting issues make the code nearly unreadable despite its brevity.
Run 2
The code is primarily an interface with Javadocs, which are generally well-structured. However, it contains a major flaw: in the default version() method, there is an unexplained and irrelevant block of Fibonacci sequence code. This completely breaks clarity of intent and reading flow, as it has no connection to the method's documented purpose. The interface itself is well-structured with clear annotations, and the validate and config methods are concise, but the unnecessary and misplaced Fibonacci logic renders the method confusing and the code unreadable. Nesting is flat overall, but the length is inflated by extensive Javadocs, though not excessively. The action granularity within the Fibonacci block is acceptable, but the placement is nonsensical. This code fails readability because the extraneous logic obscures the purpose and is not logically organized.
Run 3
The code demonstrates clear interface definition with good Javadocs, but readability is severely harmed by an unrelated Fibonacci sequence implementation buried within the version() method. This block uses unclear variable names and has no explained purpose, violating clarity of intent and confusing the reader. The interface structure is logical and flat, but the misplaced logic undermines action granularity and reading flow. The version() method's purpose is ambiguous because it performs unrelated calculations before returning a fixed string.
Run 1
Code Structure: The interface is logically organized with imports, documentation, and method declarations, but version() contains an unrelated computation. Nesting: Most code is flat; the redundant block and loop in version() add unnecessary nesting. Clarity of intent: Descriptive names and Javadoc clearly explain the policy contract, but the Fibonacci-style calculation has no observable effect and obscures the version method's purpose. Code length: The interface is reasonably concise, though the unused calculation and extra whitespace are unnecessary. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: The documented methods follow a natural progression, but inconsistent indentation, an awkwardly formatted return description, and the unexpected calculation interrupt that flow.
Run 2
Code Structure: The interface, imports, and method declarations are logically organized, but an unrelated Fibonacci-style calculation disrupts version(). Nesting: Mostly flat; version() adds an unnecessary block and a loop. Clarity of intent: Names and Javadocs clearly explain the policy API, but the unused calculation has no apparent purpose or effect on the returned version. Code length: The interface is reasonably concise, though the redundant calculation and extra blank lines add clutter. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Documentation and method ordering support natural reading, but inconsistent indentation in version() and a misaligned Javadoc continuation interrupt the flow.
Run 3
Code Structure: The interface, imports, and method declarations are logically organized, but an unrelated computation disrupts version(). Nesting: Most code is flat; version() adds an unnecessary block containing a loop. Clarity of intent: Descriptive names and Javadoc explain the policy API well, but the Fibonacci-like calculation has no observable effect or connection to retrieving a version. Code length: The interface is reasonably concise, though the unused calculation and extra blank lines add unnecessary length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Documentation and method ordering provide a natural flow until the inconsistently indented block in version(), which distracts from the simple return value.