Hi Everyone, Just a ping to bring the discussion up.
Thanks, Mario. Il giorno mar 27 gen 2026 alle ore 09:17 Mario Fiore Vitale < [email protected]> ha scritto: > Hi Chris, > > Thanks for the feedback. I updated the wrong Javadoc. > > Any other comments from anybody? > > Thanks, > Mario. > > Il giorno ven 23 gen 2026 alle ore 07:31 Chris Egerton < > [email protected]> ha scritto: > >> Hi Mario, >> >> Thanks for the updates, especially the comprehensive compatibility >> section! >> The KIP looks good to me, though you may want to double-check the example >> Javadocs on ConnectRestExtension::config >> and ConnectorClientConfigOverridePolicy::config :) >> >> Cheers, >> >> Chris >> >> On Thu, Jan 22, 2026 at 5:54 AM Mario Fiore Vitale via dev < >> [email protected]> wrote: >> >> > Hi Chris, thanks for your valuable feedback! >> > >> > > 1. (Minor) The Javadoc for HeaderConverter::config is a little >> > strange--is >> > it meant to refer to "this set of header converters" or should it just >> be >> > "this header converter"? >> > >> > This was just taken from the current source. But I agree that it should >> be >> > "this header converter". >> > >> > > For example, there's the obvious case >> > where a plugin instantiates an object with a left-hand-type of >> > ConfigSpecifier in its constructor. That plugin would be incompatible >> with >> > older versions of Connect. >> > >> > Do you have an example of this? As you said, it's unlikely that this >> would >> > occur in practice, also to me. >> > >> > > If a plugin explicitly >> > implements ConfigSpecifier, would that break compatibility? >> > >> > In this case, it should. >> > >> > > If a plugin >> > doesn't explicitly implement ConfigSpecifier, would that break >> > compatibility? >> > >> > This should not break it. >> > >> > > These are the two cases that come to mind immediately but if >> > any others occur to you feel free to document them as well. >> > >> > No other cases come to mind. I'll update the compatibility section with >> the >> > forward compatibility consideration. >> > >> > > There's also the pluggable ConnectRestExtension >> > and ConnectorClientConfigOverridePolicy interfaces. Neither currently >> > exposes a config method but it wouldn't be out of the question to add >> one >> > now to them with a default implementation that returns an empty >> ConfigDef. >> > >> > Well, I would say that since they are `Configurable`, I could expect >> that >> > maybe in some future there could also be the possibility to declare a >> > specific configuration. >> > So your proposal to add it and implement it as a default seems good to >> me. >> > >> > Regards, >> > Mario. >> > >> > >> > Il giorno gio 22 gen 2026 alle ore 04:33 Chris Egerton < >> > [email protected]> ha scritto: >> > >> > > Hi Mario, >> > > >> > > Thanks for the KIP! My thoughts: >> > > >> > > 1. (Minor) The Javadoc for HeaderConverter::config is a little >> > strange--is >> > > it meant to refer to "this set of header converters" or should it >> just be >> > > "this header converter"? >> > > >> > > 2. The compatibility problem with Connect is always gnarly. The >> section >> > on >> > > backward compatibility is very well done in that it demonstrates with >> > > certainty that older plugins will be able to run smoothly on newer >> > versions >> > > of the Connect runtime. However, there's also the question of whether >> > newer >> > > plugins (compiled against a future version of the Connect API with the >> > > change proposed in this KIP) will continue to be compatible with older >> > > versions of the Connect runtime. For example, there's the obvious case >> > > where a plugin instantiates an object with a left-hand-type of >> > > ConfigSpecifier in its constructor. That plugin would be incompatible >> > with >> > > older versions of Connect. It's unlikely that this would occur in >> > practice >> > > and even if it does, I think it's fine to accept that as a tradeoff. >> > > However, it'd be nice to see the compatibility section explore exactly >> > what >> > > would render a plugin compiled against the newer Connect API >> incompatible >> > > with older versions of the Connect runtime. If a plugin explicitly >> > > implements ConfigSpecifier, would that break compatibility? If a >> plugin >> > > doesn't explicitly implement ConfigSpecifier, would that break >> > > compatibility? These are the two cases that come to mind immediately >> but >> > if >> > > any others occur to you feel free to document them as well. This >> coverage >> > > can also help guide us in how to document the interface if/when we >> add it >> > > to make it clear to plugin developers how to avoid rendering their >> work >> > > accidentally incompatibile with older versions of the Connect runtime. >> > > >> > > 3. There's also the pluggable ConnectRestExtension >> > > and ConnectorClientConfigOverridePolicy interfaces. Neither currently >> > > exposes a config method but it wouldn't be out of the question to add >> one >> > > now to them with a default implementation that returns an empty >> > ConfigDef. >> > > Thoughts? >> > > >> > > Cheers, >> > > >> > > Chris >> > > >> > > On Wed, Jan 21, 2026 at 10:33 AM Mario Fiore Vitale via dev < >> > > [email protected]> wrote: >> > > >> > > > Hi Everyone, >> > > > >> > > > I would like to start a discussion on KIP-1273: Improve Connect >> > > > configurable components discoverability [1]. >> > > > >> > > > Summary: >> > > > The idea is to introduce a common ConfigSpecifier interface for >> Kafka >> > > > Connect components that expose configuration metadata. By unifying >> the >> > > > existing config() method across connectors, converters, >> > transformations, >> > > > and predicates under a single contract, it simplifies component >> > > discovery, >> > > > reduces code duplication and enables uniform tooling for >> configuration >> > > > introspection, validation, documentation, and UI generation. The >> change >> > > is >> > > > fully backward compatible and requires no modifications to existing >> > > > component implementations. >> > > > >> > > > [1] >> > > > >> > > > >> > > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1273%3A+Improve+Connect+configurable+components+discoverability >> > > > >> > > > Regards, >> > > > Mario >> > > > >> > > >> > >> >
