Hi Mario,
Thanks for the KIP.
Today the mechanism to discover plugins and their configurations is
the REST API.
You can retrieve the list of all installed connectors plugins
(connectors, transformations, predicates) via GET
/connector-plugins?connectorsOnly=false
You can get their configurations via GET /connector-plugins/{plugin}/config
That said, I'm not against bringing consistency to the plugin APIs,
especially as the drawbacks are really minor.
In terms of naming I'm not a huge fan of ConfigSpecifier. I don't have
a great alternative to suggest.
To follow the naming of Versioned, maybe we can consider Configured?
Otherwise we could have a ConnectorPlugin interface (putting aside the
worker plugins for now as they don't have a config() method) bringing
config() and version() that all plugins interface would implement?
Thanks,
Mickael
On Mon, Feb 2, 2026 at 9:48 AM Mario Fiore Vitale via dev
<[email protected]> wrote:
>
> 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
> >> > > >
> >> > >
> >> >
> >>
> >
