Status

Current state: Under Discussion

Discussion thread: TBD

JIRA: TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Kafka Connect provides a rich ecosystem of pluggable components, including Connectors, Converters, Transformations, and Predicates.
Each of these component types exposes configuration metadata through a config() method that returns a ConfigDef object describing the configuration properties the component accepts.

However, this config() method is currently defined independently across multiple interfaces and classes:

public abstract class Connector implements Versioned {
	
	public abstract ConfigDef config();
}

public interface Converter {
	
	default ConfigDef config() {
		return new ConfigDef();
	}
}

public interface HeaderConverter extends Configurable, Closeable {

    ConfigDef config();
}


public interface Transformation<R extends ConnectRecord<R>> extends Configurable, Closeable {
	
	ConfigDef config();
}

public interface Predicate<R extends ConnectRecord<R>> extends Configurable, AutoCloseable {
	
	ConfigDef config();
}

This fragmentation creates several challenges:

Component Discovery: Tools that need to discover and introspect component configurations must search for multiple different interfaces/classes. There is no single, unified mechanism to identify all classes that provide configuration specifications.  

Code Duplication: The same method signature is duplicated across multiple interfaces.
  
Extensibility: Future component types that require configuration specification must remember to implement the config() method independently, without compile-time enforcement of a common contract.  

Tooling Complexity: External tools (such as schema generators, UI builders, validation frameworks, and documentation generators) must maintain separate logic to handle each component type, increasing maintenance burden and the risk of inconsistencies. 

This improvement benefits several use cases:  
  
- Schema Generation: Tools like Debezium's schema generator need to automatically extract configuration metadata from components to generate descriptors for UI applications.  
- Configuration Validation: Build-time and runtime validation tools can uniformly discover and validate configurations across all component types.  
- Documentation Generation: Automated documentation tools can consistently extract and present configuration options.  
- Configuration Management UIs: Web interfaces for managing Kafka Connect deployments (like Debezium Platform) need to dynamically discover available components and their configuration requirements.  

Public Interfaces

The idea is to introduce a new interface in the org.apache.kafka.connect.components package:  
  

package org.apache.kafka.connect.components;  
  
import org.apache.kafka.common.config.ConfigDef;  
  
/**  
* Interface for components that provide configuration specifications. 
* This interface establishes a common contract for all Kafka Connect components 
* that expose configurable properties, enabling uniform discovery and introspection 
* of component configurations. 
* 
* <p>Components implementing this interface declare their configuration requirements 
* through a {@link ConfigDef} object, which describes the configuration properties 
* including their names, types, default values, validators, and documentation. 
  
* 
*/

public interface ConfigSpecifier {  
  
	/**     
	* Returns the configuration specification for this component.     
	*     
	* <p>The returned {@link ConfigDef} object describes all configuration properties     
	* that this component accepts, including their types, default values, validators,     
	* importance levels, and documentation strings.     
	*     
	* @return the configuration definition for this component; never null     
	*/    

	ConfigDef config();
}  

The following existing interfaces will be modified to extend ConfigSpecifier:  
  

public abstract class Connector implements Versioned, ConfigSpecifier {  
  
    /**     
    * Define the configuration for the connector.     
    * @return The ConfigDef for this connector; may not be null.     
    */    
    
    @Override    
    public abstract ConfigDef config();
}  

public interface Converter extends Closeable, ConfigSpecifier {  
  
    /**     
    * Configuration specification for this converter.     
    * @return the configuration specification; may not be null     
    */    
    
    @Override    
    default ConfigDef config() { return new ConfigDef();}
}  

public interface Converter extends Closeable, ConfigSpecifier {  
  
    /**     
    * Configuration specification for this converter.     
    * @return the configuration specification; may not be null     
    */    
    
    @Override    
    default ConfigDef config() { return new ConfigDef();}
}  

public interface Transformation<R extends ConnectRecord<R>> extends Configurable, Closeable, ConfigSpecifier {  
  
    /** Configuration specification for this transformation. 
    */    
    
    @Override    
    ConfigDef config();
}  

public interface Predicate<R extends ConnectRecord<R>> extends Configurable, AutoCloseable, ConfigSpecifier {  
  
    /**     
    * Configuration specification for this predicate.     
    *     
    * @return the configuration definition for this predicate; never null     
    */    
    
    @Override    
    ConfigDef config();
}  

Proposed Changes

Implementation Plan  

  
1. Introduce ConfigSpecifier Interface  
   - Add the new org.apache.kafka.connect.components.ConfigSpecifier interface to the connect-api module  
   - Include comprehensive JavaDoc explaining the purpose and usage  
  
2. Update Existing Interfaces 
   - Modify Connector, Converter, Transformation, and Predicate to extend ConfigSpecifier 
   - Preserve all existing method signatures and semantics  

Compatibility, Deprecation, and Migration Plan

This change is fully backward compatible:  
  
1. Source Compatibility: Existing component implementations are not required to change. They already implement the config() method, which satisfies the new interface requirement.  
  
2. Binary Compatibility: The change only adds a new interface to the type hierarchy. Existing compiled classes will continue to work without recompilation.  
  
3. Behavioral Compatibility: No changes to method signatures, return types, or semantics. All existing code will behave identically.  
  

Migration Path    

For Component Developers:  
- No changes required. Existing implementations already satisfy the new interface contract.  
- Optional: Add @Override annotations for clarity and compile-time checking.  
  
For Tool Developers:  
- Can immediately start using ConfigSpecifier to discover components uniformly.  
- Existing type-specific discovery code continues to work and can be gradually migrated.  
- The new interface provides an additive capability without breaking existing approaches.  

Deprecation  
  

No deprecation is necessary. The existing config() methods in individual interfaces remain valid; they simply gain a common ancestor.  

Test Plan

All current tests should be fine to detect any issues.

Rejected Alternatives

None