I felt the same need when we want to add a pluggable API for core server functionality. This does not need to be part of this KIP, it can be a separate KIP. I can contribute those refactoring changes if others are OK with that.
It is better to have a structure like below. kafka-common: common classes which can be used in any of the other modules in Kafka like client, Kafka-server-common and server etc. kafka-client-common: common classes which can be used in the client module. This can be part of client module itself. kafka-server-common: classes required only for kafka-server. Thanks. Satish. On Wed, Aug 7, 2019 at 9:28 PM Harsha Chintalapani <ka...@harsha.io> wrote: > > Thanks for the KIP Rajini. > Quick thought, it would be good to have a common module outside of clients > that only applies to server side interfaces & changes. It looks like we are > increasingly in favor of using Java interface for pluggable modules on the > broker side. > > Thanks, > Harsha > > > On Tue, Aug 06, 2019 at 2:31 PM, Rajini Sivaram <rajinisiva...@gmail.com> > wrote: > > > Hi all, > > > > I have created a KIP to replace the Scala Authorizer API with a new Java > > API: > > > > - > > https://cwiki.apache.org/confluence/display/KAFKA/ > > KIP-504+-+Add+new+Java+Authorizer+Interface > > > > This is replacement for KIP-50 which was accepted but never merged. Apart > > from moving to a Java API consistent with other pluggable interfaces in the > > broker, KIP-504 also attempts to address known limitations in the > > authorizer. If you have come across other limitations that you would like > > to see addressed in the new API, please raise these on the discussion > > thread so that we can consider those too. All suggestions and feedback are > > welcome. > > > > Thank you, > > > > Rajini > >
