From dev-return-105681-archive-asf-public=cust-asf.ponee.io@kafka.apache.org Fri Jul 12 19:35:34 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 08E591802C7 for ; Fri, 12 Jul 2019 21:35:33 +0200 (CEST) Received: (qmail 12243 invoked by uid 500); 12 Jul 2019 19:35:31 -0000 Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@kafka.apache.org Delivered-To: mailing list dev@kafka.apache.org Received: (qmail 12230 invoked by uid 99); 12 Jul 2019 19:35:31 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jul 2019 19:35:31 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id CED851A32AA for ; Fri, 12 Jul 2019 19:35:30 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=confluent.io Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 15U9NmCSIALI for ; Fri, 12 Jul 2019 19:35:27 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.208.66; helo=mail-ed1-f66.google.com; envelope-from=andy@confluent.io; receiver= Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 310EDBC773 for ; Fri, 12 Jul 2019 19:35:27 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id m10so10145893edv.6 for ; Fri, 12 Jul 2019 12:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=confluent.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=jA2C/89hLLUoIxYb5bgkOWi3MiV5N1AsxOM5whgMGEk=; b=QY/vorkRkv24y2eDD5efaf5dEJC1BHF8+bUV5FvRQ9U40sdihaY0UrfJI9QEAaj638 IkknXbv0WbiP28WjKrD0vHpU744kDJPtUYifWq+uyzQ88qvxaqDKr676jrInxtSL+lGf rpqrrQ/Y0CHUzR+8tE4AweJmmTZFp8J/mpqQeLz+uZEzCghE3gCzA3DV/Dftcdp+QD3b mOFo54w5qMnimqzoKhsyGcEETww0v4dxpXfpUE+LhqoRfJA2E6IIl4ClUBkBu3ddGVYk 8jLtOtLLieYebIcXoqipGVizHG+cfBN/Mu5aEnTZCtPAYQ2hu4rXjzgmx6ai/FLPurKv 6Cuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=jA2C/89hLLUoIxYb5bgkOWi3MiV5N1AsxOM5whgMGEk=; b=rUlzPfTF1afwvSBZF6y8ucOIXHjzFkZsh+ZqpbVEkS7KNjHRoiwGRfD6QpjXhrNG0o zUau7H4b6ho38df/NL8pfVqyb18RUYoCe2Thao5TxT2Y2Xp+fRmQbP0n23YeuVg1PAmj foa4dWSmH9hOlEBrHLTiFk+IUhAeW+gcNcSouo9/hKOFmX1RTcBIM/nWo/pcfFoysfXu XADnhgyCzqW3VkmafucGOLxY64VymbksTynmce7A1YpZqUTPSKFH3anv+f5rqFANslFF A7H0PvdTbnjENRgkw4OJJ/swGiTP5p8R9oYfgLLT6IOmAnf6TuuhqW930hAW4HlHZpO8 XpdA== X-Gm-Message-State: APjAAAWX+KJvdK87GRknq2AspnrujdyAMx2lma3PhRf7QB3qafkg1hQN AVyPKLqYc/p1PFc+0dBRAVG6uvVZ4gmkMKK3S5Uj0oUrwFg= X-Google-Smtp-Source: APXvYqw86MuxMlko4OSigFfaCL6kLCtXPwGCIF9LXmpPrQUAfkEZNsDBxcWsxUGqdsbmvupz/29+rTReVT47EB4NfWA= X-Received: by 2002:a17:906:244c:: with SMTP id a12mr9579562ejb.288.1562960125723; Fri, 12 Jul 2019 12:35:25 -0700 (PDT) MIME-Version: 1.0 References: <7AD3B8C7-04E4-49E2-A036-8D8FE918607F@confluent.io> <8923d8f3-61fd-e213-517a-de701a6dd7b5@confluent.io> <7dc1464a-4a17-0cac-8b66-bf7cdf18e4ee@confluent.io> <8de49276-6ab1-46ff-aeac-c18001cf70cd@www.fastmail.com> <1e1bc9a2-9d6c-70f3-2b6e-d017895d22d0@confluent.io> In-Reply-To: From: Andy Coates Date: Fri, 12 Jul 2019 20:35:14 +0100 Message-ID: Subject: Re: [VOTE] KIP-476: Add Java AdminClient interface To: dev Content-Type: multipart/alternative; boundary="00000000000017b468058d8103fd" --00000000000017b468058d8103fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Awesome sauce - so I'd like to close the voting. final vote was: 4 for binding, none against 3 non-binding, none against. I'll update the KIP to reflect the passing of the vote. Thanks you all for your time & brain power, Andy On Thu, 11 Jul 2019 at 14:51, Rajini Sivaram wrote: > +1 (binding) > > Thanks for the KIP, Andy! > > Regards, > > Rajini > > > On Thu, Jul 11, 2019 at 1:18 PM Gwen Shapira wrote: > > > +1 (binding) > > > > Thank you for the improvement. > > > > On Thu, Jul 11, 2019, 3:53 AM Andy Coates wrote: > > > > > Hi All, > > > > > > So voting currently stands on: > > > > > > Binding: > > > +1 Matthias, > > > +1 Colin > > > > > > Non-binding: > > > +1 Thomas Becker > > > +1 Satish Guggana > > > +1 Ryan Dolan > > > > > > So we're still 1 binding vote short. :( > > > > > > > > > On Wed, 3 Jul 2019 at 23:08, Matthias J. Sax > > > wrote: > > > > > > > Thanks for the details Colin and Andy. > > > > > > > > My indent was not to block the KIP, but it seems to be a fair > question > > > > to ask. > > > > > > > > I talked to Ismael offline about it and understand his reasoning > better > > > > now. If we don't deprecate `abstract AdminClient` class, it seems > > > > reasonable to not deprecate the corresponding factory methods eithe= r. > > > > > > > > > > > > +1 (binding) on the current proposal > > > > > > > > > > > > > > > > -Matthias > > > > > > > > On 7/3/19 5:03 AM, Andy Coates wrote: > > > > > Matthias, > > > > > > > > > > I was referring to platforms such as spark or flink that support > > > multiple > > > > > versions of the Kafka clients. Ismael mentioned this higher up on > the > > > > > thread. > > > > > > > > > > I'd prefer this KIP didn't get held up over somewhat unrelated > > change, > > > > i.e. > > > > > should the factory method be on the interface or utility class. > > > Surely, > > > > > now would be a great time to change this if we wanted, but we can > > also > > > > > change this later if we need to. In the interest of moving > forward, > > > can > > > > I > > > > > propose we leave the factory methods as they are in the KIP? > > > > > > > > > > Thanks, > > > > > > > > > > Andy > > > > > > > > > > On Tue, 2 Jul 2019 at 17:14, Colin McCabe > > wrote: > > > > > > > > > >> On Tue, Jul 2, 2019, at 09:14, Colin McCabe wrote: > > > > >>> On Mon, Jul 1, 2019, at 23:30, Matthias J. Sax wrote: > > > > >>>> Not sure, if I understand the argument? > > > > >>>> > > > > >>>> Why would anyone need to support multiple client side versions= ? > > > > >>>> Clients/brokers are forward/backward compatible anyway. > > > > >>> > > > > >>> When you're using many different libraries, it is helpful if th= ey > > > don't > > > > >>> impose tight constraints on what versions their dependencies ar= e. > > > > >>> Otherwise you can easily get in a situation where the constrain= ts > > > can't > > > > >>> be satisfied. > > > > >>> > > > > >>>> > > > > >>>> Also, if one really supports multiple client side versions, > won't > > > they > > > > >>>> use multiple shaded dependencies for different versions? > > > > >>> > > > > >>> Shading the Kafka client doesn't really work, because of how we > use > > > > >> reflection. > > > > >>> > > > > >>>> > > > > >>>> Last, it's possible to suppress warnings (at least in Java). > > > > >>> > > > > >>> But not in Scala. So that does not help (for example), Scala > > users. > > > > >> > > > > >> I meant to write "Spark users" here. > > > > >> > > > > >> C. > > > > >> > > > > >>> > > > > >>> I agree that in general we should be using deprecation when > > > > >>> appropriate, regardless of the potential annoyances to users. > But > > > I'm > > > > >>> not sure deprecating this method is really worth it. > > > > >>> > > > > >>> best, > > > > >>> Colin > > > > >>> > > > > >>> > > > > >>>> > > > > >>>> Can you elaborate? > > > > >>>> > > > > >>>> IMHO, just adding a statement to JavaDocs is a little weak, an= d > at > > > > some > > > > >>>> point, we need to deprecate those methods anyway if we ever wa= nt > > to > > > > >>>> remove them. The earlier we deprecate them, the earlier we can > > > remove > > > > >> them. > > > > >>>> > > > > >>>> > > > > >>>> -Matthias > > > > >>>> > > > > >>>> On 7/1/19 4:22 AM, Andy Coates wrote: > > > > >>>>> Done. I've not deprecated the factory methods on the > AdminClient > > > for > > > > >> the > > > > >>>>> same reason the AdminClient itself is not deprecated, i.e. th= is > > > > >> would cause > > > > >>>>> unavoidable warnings for libraries / platforms that support > > > multiple > > > > >>>>> versions of Kafka. However, I think we add a note to the Java > > docs > > > of > > > > >>>>> `AdminClient` to indicate that its use, going forward, is > > > > >> discouraged in > > > > >>>>> favour of the new `Admin` interface and explain why its not > been > > > > >>>>> deprecated, but that it may/will be removed in a future > version. > > > > >>>>> > > > > >>>>> Regarding factory methods on interfaces: there seems to be so= me > > > > >> difference > > > > >>>>> of opinion here. I'm not sure of the best approach to revolve > > this. > > > > >> At the > > > > >>>>> moment the KIP has factory methods on the new `Admin` > interface, > > > > >> rather > > > > >>>>> than some utility class. I prefer the utility class, but this > > isn't > > > > >> inline > > > > >>>>> with the patterns in the code base and some of the core team > have > > > > >> expressed > > > > >>>>> they'd prefer to continue to have the factory methods on the > > > > >> interface. > > > > >>>>> I'm happy with this if others are. > > > > >>>>> > > > > >>>>> Thanks, > > > > >>>>> > > > > >>>>> Andy > > > > >>>>> > > > > >>>>> On Thu, 27 Jun 2019 at 23:21, Matthias J. Sax < > > > matthias@confluent.io > > > > > > > > > >> wrote: > > > > >>>>> > > > > >>>>>> @Andy: > > > > >>>>>> > > > > >>>>>> What about the factory methods of `AdminClient` class? Shoul= d > > they > > > > >> be > > > > >>>>>> deprecated? > > > > >>>>>> > > > > >>>>>> One nit about the KIP: can you maybe insert "code blocks" to > > > > >> highlight > > > > >>>>>> the API changes? Code blocks would simplify to read the KIP = a > > lot. > > > > >>>>>> > > > > >>>>>> > > > > >>>>>> -Matthias > > > > >>>>>> > > > > >>>>>> On 6/26/19 6:56 AM, Ryanne Dolan wrote: > > > > >>>>>>> +1 (non-binding) > > > > >>>>>>> > > > > >>>>>>> Thanks. > > > > >>>>>>> Ryanne > > > > >>>>>>> > > > > >>>>>>> On Tue, Jun 25, 2019 at 10:21 PM Satish Duggana < > > > > >>>>>> satish.duggana@gmail.com> > > > > >>>>>>> wrote: > > > > >>>>>>> > > > > >>>>>>>> +1 (non-binding) > > > > >>>>>>>> > > > > >>>>>>>> On Wed, Jun 26, 2019 at 8:37 AM Satish Duggana < > > > > >>>>>> satish.duggana@gmail.com> > > > > >>>>>>>> wrote: > > > > >>>>>>>>> > > > > >>>>>>>>> +1 Matthias/Andy. > > > > >>>>>>>>> IMHO, interface is about the contract, it should not > > > have/expose > > > > >> any > > > > >>>>>>>>> implementation. I am fine with either way as it is more o= f > > > taste > > > > >> or > > > > >>>>>>>>> preference. > > > > >>>>>>>>> > > > > >>>>>>>>> Agree with Ismael/Colin/Ryanne on not deprecating for goo= d > > > > >> reasons. > > > > >>>>>>>>> > > > > >>>>>>>>> > > > > >>>>>>>>> On Mon, Jun 24, 2019 at 8:33 PM Andy Coates < > > andy@confluent.io > > > > > > > > >> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>> I agree Matthias. > > > > >>>>>>>>>> > > > > >>>>>>>>>> (In Scala, such factory methods are on a companion objec= t. > > As > > > > >> Java > > > > >>>>>>>> doesn't > > > > >>>>>>>>>> have the concept of a companion object, an equivalent > would > > > be a > > > > >>>>>>>> utility > > > > >>>>>>>>>> class with a similar name...) > > > > >>>>>>>>>> > > > > >>>>>>>>>> However, I'll update the KIP to include the factory meth= od > > on > > > > >> the > > > > >>>>>>>> interface. > > > > >>>>>>>>>> > > > > >>>>>>>>>> On Fri, 21 Jun 2019 at 23:40, Matthias J. Sax < > > > > >> matthias@confluent.io> > > > > >>>>>>>> wrote: > > > > >>>>>>>>>> > > > > >>>>>>>>>>> I still think, that an interface does not need to know > > > > >> anything about > > > > >>>>>>>>>>> its implementation. But I am also fine if we add a > factory > > > > >> method to > > > > >>>>>>>> the > > > > >>>>>>>>>>> new interface if that is preferred by most people. > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> -Matthias > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> On 6/21/19 7:10 AM, Ismael Juma wrote: > > > > >>>>>>>>>>>> This is even more reason not to deprecate immediately, > > there > > > > >> is > > > > >>>>>>>> very > > > > >>>>>>>>>>> little > > > > >>>>>>>>>>>> maintenance cost for us. We should be mindful that man= y > of > > > our > > > > >>>>>>>> users (eg > > > > >>>>>>>>>>>> Spark, Flink, etc.) typically allow users to specify t= he > > > kafka > > > > >>>>>>>> clients > > > > >>>>>>>>>>>> version and hence avoid using new classes/interfaces f= or > > > some > > > > >>>>>>>> time. They > > > > >>>>>>>>>>>> would get a bunch of warnings they cannot do anything > > about > > > > >> apart > > > > >>>>>>>> from > > > > >>>>>>>>>>>> suppressing. > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> Ismael > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>> On Fri, Jun 21, 2019 at 4:00 AM Andy Coates < > > > > >> andy@confluent.io> > > > > >>>>>>>> wrote: > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>>>> Hi Ismael, > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> I=E2=80=99m happy enough to not deprecate the existin= g > > > `AdminClient` > > > > >>>>>>>> class as > > > > >>>>>>>>>>> part > > > > >>>>>>>>>>>>> of this change. > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> However, note that, the class will likely be empty, > i.e. > > > all > > > > >>>>>>>> methods and > > > > >>>>>>>>>>>>> implementations will be inherited from the interface: > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> public abstract class AdminClient implements Admin { > > > > >>>>>>>>>>>>> } > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> Not marking it as deprecated has the benefit that use= rs > > > > >> won=E2=80=99t see > > > > >>>>>>>> any > > > > >>>>>>>>>>>>> deprecation warnings on the next release. Conversely, > > > > >> deprecating > > > > >>>>>>>> it > > > > >>>>>>>>>>> will > > > > >>>>>>>>>>>>> mean we can choose to remove this, now pointless clas= s, > > in > > > > >> the > > > > >>>>>>>> future > > > > >>>>>>>>>>> if we > > > > >>>>>>>>>>>>> choose. > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> That=E2=80=99s my thinking for deprecation, but as I= =E2=80=99ve said > I=E2=80=99m > > > > >> happy > > > > >>>>>>>> either > > > > >>>>>>>>>>> way. > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> Andy > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> On 18 Jun 2019, at 16:09, Ismael Juma < > > ismael@juma.me.uk> > > > > >> wrote: > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> I agree with Ryanne, I think we should avoid > deprecating > > > > >>>>>>>> AdminClient > > > > >>>>>>>>>>> and > > > > >>>>>>>>>>>>>> causing so much churn for users who don't actually > care > > > > >> about > > > > >>>>>>>> this > > > > >>>>>>>>>>> niche > > > > >>>>>>>>>>>>>> use case. > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> Ismael > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>> On Tue, Jun 18, 2019 at 6:43 AM Andy Coates < > > > > >> andy@confluent.io> > > > > >>>>>>>> wrote: > > > > >>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> Hi Ryanne, > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> If we don't change the client code, then everywhere > > will > > > > >> still > > > > >>>>>>>> expect > > > > >>>>>>>>>>>>>>> subclasses of `AdminClient`, so the interface will = be > > of > > > no > > > > >>>>>>>> use, i.e. > > > > >>>>>>>>>>> I > > > > >>>>>>>>>>>>>>> can't write a class that implements the new interfa= ce > > and > > > > >> pass > > > > >>>>>>>> it to > > > > >>>>>>>>>>> the > > > > >>>>>>>>>>>>>>> client code. > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> Andy > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> On Mon, 17 Jun 2019 at 19:01, Ryanne Dolan < > > > > >>>>>>>> ryannedolan@gmail.com> > > > > >>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>> Andy, while I agree that the new interface is > useful, > > > I'm > > > > >> not > > > > >>>>>>>>>>> convinced > > > > >>>>>>>>>>>>>>>> adding an interface requires deprecating AdminClie= nt > > and > > > > >>>>>>>> changing so > > > > >>>>>>>>>>>>> much > > > > >>>>>>>>>>>>>>>> client code. Why not just add the Admin interface, > > have > > > > >>>>>>>> AdminClient > > > > >>>>>>>>>>>>>>>> implement it, and have done? > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>> Ryanne > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>> On Mon, Jun 17, 2019 at 12:09 PM Andy Coates < > > > > >>>>>>>> andy@confluent.io> > > > > >>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> Hi all, > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> I think I've addressed all concerns. Let me know = if > > > I've > > > > >>>>>>>> not. Can I > > > > >>>>>>>>>>>>>>> call > > > > >>>>>>>>>>>>>>>>> another round of votes please? > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> Andy > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> On Fri, 14 Jun 2019 at 04:55, Satish Duggana < > > > > >>>>>>>>>>>>> satish.duggana@gmail.com > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> Hi Andy, > > > > >>>>>>>>>>>>>>>>>> Thanks for the KIP. This is a good change and it > > gives > > > > >> the > > > > >>>>>>>> user a > > > > >>>>>>>>>>>>>>>> better > > > > >>>>>>>>>>>>>>>>>> handle on Admin client usage. I agree with the > > > proposal > > > > >>>>>>>> except the > > > > >>>>>>>>>>>>>>> new > > > > >>>>>>>>>>>>>>>>>> `Admin` interface having all the methods from > > > > >> `AdminClient` > > > > >>>>>>>>>>> abstract > > > > >>>>>>>>>>>>>>>>> class. > > > > >>>>>>>>>>>>>>>>>> It should be kept clean having only the admin > > > > >> operations as > > > > >>>>>>>> methods > > > > >>>>>>>>>>>>>>>> from > > > > >>>>>>>>>>>>>>>>>> KafkaClient abstract class but not the factory > > methods > > > > >> as > > > > >>>>>>>> mentioned > > > > >>>>>>>>>>>>>>> in > > > > >>>>>>>>>>>>>>>>> the > > > > >>>>>>>>>>>>>>>>>> earlier mail. > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> I know about dynamic proxies(which were widely > used > > in > > > > >>>>>>>> RMI/EJB > > > > >>>>>>>>>>>>>>> world). > > > > >>>>>>>>>>>>>>>> I > > > > >>>>>>>>>>>>>>>>> am > > > > >>>>>>>>>>>>>>>>>> curious about the usecase using dynamic proxies > with > > > > >> Admin > > > > >>>>>>>> client > > > > >>>>>>>>>>>>>>>>>> interface. Dynamic proxy can have performance > > penalty > > > > >> if it > > > > >>>>>>>> is used > > > > >>>>>>>>>>>>>>> in > > > > >>>>>>>>>>>>>>>>>> critical path. Is that the primary motivation fo= r > > > > >> creating > > > > >>>>>>>> the KIP? > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>>>>>>>> Satish. > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> On Wed, Jun 12, 2019 at 8:43 PM Andy Coates < > > > > >>>>>>>> andy@confluent.io> > > > > >>>>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> I'm not married to that part. That was only do= ne > > to > > > > >> keep > > > > >>>>>>>> it more > > > > >>>>>>>>>>>>>>> or > > > > >>>>>>>>>>>>>>>>> less > > > > >>>>>>>>>>>>>>>>>>> inline with what's already there, (an abstract > > class > > > > >> that > > > > >>>>>>>> has a > > > > >>>>>>>>>>>>>>>> factory > > > > >>>>>>>>>>>>>>>>>>> method that returns a subclass.... sounds like > the > > > same > > > > >>>>>>>>>>>>>>> anti-pattern > > > > >>>>>>>>>>>>>>>>> ;)) > > > > >>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> An alternative would to have an `AdminClients` > > > utility > > > > >>>>>>>> class to > > > > >>>>>>>>>>>>>>>> create > > > > >>>>>>>>>>>>>>>>>> the > > > > >>>>>>>>>>>>>>>>>>> admin client. > > > > >>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> On Mon, 10 Jun 2019 at 19:31, Matthias J. Sax < > > > > >>>>>>>>>>>>>>> matthias@confluent.io > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> Hmmm... > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> So the new interface, returns an instance of a > > class > > > > >> that > > > > >>>>>>>>>>>>>>>> implements > > > > >>>>>>>>>>>>>>>>>> the > > > > >>>>>>>>>>>>>>>>>>>> interface. This sounds a little bit like an > > > > >> anti-pattern? > > > > >>>>>>>>>>>>>>> Shouldn't > > > > >>>>>>>>>>>>>>>>>>>> interfaces actually not know anything about > > classes > > > > >> that > > > > >>>>>>>>>>>>>>> implement > > > > >>>>>>>>>>>>>>>>> the > > > > >>>>>>>>>>>>>>>>>>>> interface? > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> -Matthias > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> On 6/10/19 11:22 AM, Andy Coates wrote: > > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient` would be deprecated purely > because > > it > > > > >> would > > > > >>>>>>>> no > > > > >>>>>>>>>>>>>>>> longer > > > > >>>>>>>>>>>>>>>>>>> serve > > > > >>>>>>>>>>>>>>>>>>>>> any purpose and would be virtually empty, > getting > > > > >> all of > > > > >>>>>>>> its > > > > >>>>>>>>>>>>>>>>>>>> implementation > > > > >>>>>>>>>>>>>>>>>>>>> from the new interfar. It would be nice to > remove > > > > >> this > > > > >>>>>>>> from the > > > > >>>>>>>>>>>>>>>> API > > > > >>>>>>>>>>>>>>>>>> at > > > > >>>>>>>>>>>>>>>>>>>> the > > > > >>>>>>>>>>>>>>>>>>>>> next major version bump, hence the need to > > > deprecate. > > > > >>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>> `AdminClient.create()` would return what it > does > > > > >> today, > > > > >>>>>>>> (so > > > > >>>>>>>>>>>>>>> not a > > > > >>>>>>>>>>>>>>>>>>>> breaking > > > > >>>>>>>>>>>>>>>>>>>>> change). > > > > >>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>> On Tue, 4 Jun 2019 at 22:24, Ryanne Dolan < > > > > >>>>>>>>>>>>>>> ryannedolan@gmail.com > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> The existing `AdminClient` will be marked a= s > > > > >> deprecated. > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>> What's the reasoning behind this? I'm fine > with > > > the > > > > >> other > > > > >>>>>>>>>>>>>>>> changes, > > > > >>>>>>>>>>>>>>>>>> but > > > > >>>>>>>>>>>>>>>>>>>>>> would prefer to keep the existing public API > > > intact > > > > >> if > > > > >>>>>>>> it's > > > > >>>>>>>>>>>>>>> not > > > > >>>>>>>>>>>>>>>>>>> hurting > > > > >>>>>>>>>>>>>>>>>>>>>> anything. > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>> Also, what will AdminClient.create() return? > > Would > > > > >> it be > > > > >>>>>>>> a > > > > >>>>>>>>>>>>>>>>> breaking > > > > >>>>>>>>>>>>>>>>>>>> change? > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>> Ryanne > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>> On Tue, Jun 4, 2019, 11:17 AM Andy Coates < > > > > >>>>>>>> andy@confluent.io> > > > > >>>>>>>>>>>>>>>>>> wrote: > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> Hi folks > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> As there's been no chatter on this KIP I'm > > > > >> assuming it's > > > > >>>>>>>>>>>>>>>>>>>> non-contentious, > > > > >>>>>>>>>>>>>>>>>>>>>>> (or just boring), hence I'd like to call a > vote > > > for > > > > >>>>>>>> KIP-476: > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>> > > > > >>>>>> > > > > >> > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-476%3A+Add+Java+Adm= inClient+Interface > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> Thanks, > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>>> Andy > > > > >>>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>>> > > > > >>>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>>>>> > > > > >>>>>>>> > > > > >>>>>>> > > > > >>>>>> > > > > >>>>>> > > > > >>>>> > > > > >>>> > > > > >>>> > > > > >>>> Attachments: > > > > >>>> * signature.asc > > > > >>> > > > > >> > > > > > > > > > > > > > > > > > > > --00000000000017b468058d8103fd--