Status

Current state: Under Discussion

...

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.

...

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:  
  

...

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