ATM, StreamsConfig is immutable. Thus, it's just boiler plate code for the user.
If we really add a builder pattern or change StreamsConfig, we can update the API accordingly. We will need a KIP for those changes anyway. But for now, it seems to be best to avoid boiler plate if possible. Just my 2 cents. -Matthias On 1/16/18 9:59 AM, Colin McCabe wrote: > Why not just have a StreamsConfig constructor that takes a Properties object? > This has a few advantages. Firstly, because it's purely additive, it > doesn't create any deprecated functions or compatibility issues that we have > to clean up later. Secondly, if we decide to do something interesting with > StreamsConfig later, we still have it. For example, we could have a builder, > or some interesting ways to serialize it or send it to a string. > > best, > Colin > > > On Tue, Jan 16, 2018, at 09:54, Matthias J. Sax wrote: >> Thanks for updating the KIP. >> >> I am recasting my vote +1 (binding). >> >> >> -Matthias >> >> On 1/13/18 4:30 AM, Boyang Chen wrote: >>> Hey Matt and Guozhang, >>> >>> >>> I have already updated the pull >>> request: https://github.com/apache/kafka/pull/4354 >>> >>> and the >>> KIP: >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-245%3A+Use+Properties+instead+of+StreamsConfig+in+KafkaStreams+constructor >>> >>> >>> to reflect the change proposed by Guozhang(adding a 4th constructor) >>> >>> >>> Let me know your thoughts! >>> >>> >>> Best, >>> >>> Boyang >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Boyang Chen <bche...@outlook.com> >>> *Sent:* Saturday, January 13, 2018 9:37 AM >>> *To:* Matthias J. Sax >>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>> in KafkaStreams constructor >>> >>> >>> Sounds good, will do. However I don't receive the +1 emails, interesting... >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Matthias J. Sax <matth...@confluent.io> >>> *Sent:* Saturday, January 13, 2018 9:32 AM >>> *To:* Boyang Chen >>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>> in KafkaStreams constructor >>> >>> Guozhang left a comment about having a 4th overload. I agree that we >>> should add this 4th overload. >>> >>> Please update the KIP accordingly and follow up on the mailing list >>> thread. Than we can vote it through. >>> >>> Thx. >>> >>> -Matthias >>> >>> On 1/12/18 4:48 PM, Boyang Chen wrote: >>>> Hey Matt, >>>> >>>> >>>> I haven't received any approval/veto on this KIP. Everything is ready >>>> but only needs one approval. Any step I should take? >>>> >>>> Thanks for the help! >>>> >>>> Boyang >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Matthias J. Sax <matth...@confluent.io> >>>> *Sent:* Saturday, January 13, 2018 3:47 AM >>>> *To:* dev@kafka.apache.org >>>> *Subject:* Re: Vote for KIP-245: Use Properties instead of StreamsConfig >>>> in KafkaStreams constructor >>>> >>>> Boyang, >>>> >>>> what is the status of this KIP? The release plan for 1.1 was just >>>> announced and we like to get this KIP into the release. >>>> >>>> Thx. >>>> >>>> >>>> -Matthias >>>> >>>> On 1/2/18 11:18 AM, Guozhang Wang wrote: >>>>> Boyang, >>>>> >>>>> Thanks for the proposed change, the wiki page lgtm. One minor comment >>>>> otherwise I'm +1: >>>>> >>>>> For the new API, we now also have a constructor that accepts both a >>>>> clientSupplier and a Time, so we should consider having four overloads in >>>>> total: >>>>> >>>>> >>>>> // New API (using Properties) >>>>> public KafkaStreams(final Topology, final Properties props) >>>>> public KafkaStreams(final Topology, final Properties props, final Time >>>>> time) >>>>> public KafkaStreams(final Topology, final Properties props, final >>>>> KafkaClientSupplier >>>>> clientSupplier) >>>>> public KafkaStreams(final Topology, final Properties props, final >>>>> KafkaClientSupplier >>>>> clientSupplier, final Time time) >>>>> >>>>> Guozhang >>>>> >>>>> On Tue, Dec 26, 2017 at 7:26 PM, Satish Duggana <satish.dugg...@gmail.com> >>>>> wrote: >>>>> >>>>>> Thanks for the KIP, +1 from me. >>>>>> >>>>>> On Wed, Dec 27, 2017 at 7:42 AM, Bill Bejeck <bbej...@gmail.com> wrote: >>>>>> >>>>>>> Thanks for the KIP. +1 for me. >>>>>>> >>>>>>> On Tue, Dec 26, 2017 at 6:22 PM Ted Yu <yuzhih...@gmail.com> wrote: >>>>>>> >>>>>>>> +1 from me as well. >>>>>>>> >>>>>>>> On Tue, Dec 26, 2017 at 10:41 AM, Matthias J. Sax < >>>>>> matth...@confluent.io >>>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks for the KIP Boyang! >>>>>>>>> >>>>>>>>> I don't have any further comments. >>>>>>>>> >>>>>>>>> +1 from me. >>>>>>>>> >>>>>>>>> @Ted: This is a rather simple KIP, thus, skipping the DISCUSS thread >>>>>>>>> seems ok to me. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> @Boyang: it's recommended to use this format for the subject >>>>>>>>> >>>>>>>>> "[VOTE] KIP-245: ..." >>>>>>>>> >>>>>>>>> Same for DISCUSS threads. People are used to those headlines and they >>>>>>>>> pay more attention than. For this KIP, just leave it as it though. >>>>>> For >>>>>>>>> future reference only >>>>>>>>> . >>>>>>>>> >>>>>>>>> >>>>>>>>> On 12/26/17 4:55 AM, Ted Yu wrote: >>>>>>>>>> Normally a DISCUSS thread precedes VOTE thread so that people have >>>>>>>> ample >>>>>>>>> time examining the proposal. >>>>>>>>>> -------- Original message --------From: Boyang Chen < >>>>>>>> bche...@outlook.com> >>>>>>>>> Date: 12/26/17 1:22 AM (GMT-07:00) To: dev@kafka.apache.org >>>>>> Subject: >>>>>>>>> Vote for KIP-245: Use Properties instead of StreamsConfig in >>>>>>> KafkaStreams >>>>>>>>> constructor >>>>>>>>>> Hi there, >>>>>>>>>> >>>>>>>>>> I'm Boyang who is a newbie contributor to Kafka. I would like to >>>>>>> start >>>>>>>> a >>>>>>>>> vote for the KIP-245: >>>>>>>>>> >>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP- >>>>>>>>> >>>>>>>> 245%3A+Use+Properties+instead+of+StreamsConfig+in+ >>>>>>> KafkaStreams+constructor >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> This is linked with JIRA: https://issues.apache.org/ >>>> issues.apache.org <https://issues.apache.org/> >>> issues.apache.org <https://issues.apache.org/> >>> issues.apache.org >>> Apache currently hosts two different issue tracking systems, Bugzilla >>> and Jira. To find out how to report an issue for a particular project, >>> please visit the project ... >>> >>> >>> >>>> issues.apache.org >>>> Apache currently hosts two different issue tracking systems, Bugzilla >>>> and Jira. To find out how to report an issue for a particular project, >>>> please visit the project ... >>>> >>>> >>>> >>>>>>>>> jira/browse/KAFKA-6386 >>>>>>>>>> >>>>>>>>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ...< >>>>>>>>> https://issues.apache.org/jira/browse/KAFKA-6386> >>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>> issues.apache.org >>> Currently, KafkaStreams constructor has overloads that take either >>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>> immutable and is created from a ... >>> >>> >>> >>>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>> issues.apache.org >>> Currently, KafkaStreams constructor has overloads that take either >>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>> immutable and is created from a ... >>> >>> >>> >>>> issues.apache.org >>>> Currently, KafkaStreams constructor has overloads that take either >>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>> immutable and is created from a ... >>>> >>>> >>>> >>>>>>>>>> issues.apache.org >>>>>>>>>> Currently, KafkaStreams constructor has overloads that take either >>>>>>>>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>>>>>>>> immutable and is created from a ... >>>>>>>>>> >>>>>>>>>> And my pull request is here: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/apache/kafka/pull/4354 >>> <https://github.com/apache/kafka/pull/4354> >>> >>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>> <https://github.com/apache/kafka/pull/4354> >>> github.com >>> This pull request targets >>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>> created separate public constructors... >>> >>> >>> >>>> <https://github.com/apache/kafka/pull/4354> >>> <https://github.com/apache/kafka/pull/4354> >>> >>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>> <https://github.com/apache/kafka/pull/4354> >>> github.com >>> This pull request targets >>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>> created separate public constructors... >>> >>> >>> >>>> >>>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>>> <https://github.com/apache/kafka/pull/4354> >>> <https://github.com/apache/kafka/pull/4354> >>> >>> KAFKA-6386:use Properties instead of StreamsConfig in KafkaStreams >>> constructor by abbccdda · Pull Request #4354 · apache/kafka >>> <https://github.com/apache/kafka/pull/4354> >>> github.com >>> This pull request targets >>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>> created separate public constructors... >>> >>> >>> >>>> github.com >>>> This pull request targets >>>> https://issues.apache.org/jira/browse/KAFKA-6386 The minor fix to >>> [KAFKA-6386] Deprecate KafkaStreams constructor taking ... >>> <https://issues.apache.org/jira/browse/KAFKA-6386> >>> issues.apache.org >>> Currently, KafkaStreams constructor has overloads that take either >>> Properties or StreamsConfig a parameters. Because StreamsConfig is >>> immutable and is created from a ... >>> >>> >>> >>>> deprecate usage of StreamsConfig in favor of java.util.Properties. I >>>> created separate public constructors... >>>> >>>> >>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Since this is my first time doing this, feel free to let me know if >>>>>>>> this >>>>>>>>> is the correct format! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Best, >>>>>>>>>> >>>>>>>>>> Boyang >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> Email had 1 attachment: >> + signature.asc >> 1k (application/pgp-signature)
signature.asc
Description: OpenPGP digital signature
