You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Status

Current state: "Under Discussion"

Discussion thread: No discussion thread

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Currently, KafkaStreams constructor has overloads that take either Properties or StreamsConfig a parameters.

Because StreamsConfig is immutable and is created from a Properties object itself, the constructors accepting StreamsConfig are not useful and adds only boiler plate code. Thus, we should deprecate those constructors in order to remove them eventually.

Public Interfaces

// Old API (using StreamsConfig)
public KafkaStreams(final Topology, final StreamsConfig config) 
public KafkaStreams(final Topology, final StreamsConfig config, final KafkaClientSupplier clientSupplier) 
public KafkaStreams(final Topology, final StreamsConfig config, final Time time) 


// New API (using Properties)
public KafkaStreams(final Topology, final Properties props) 
public KafkaStreams(final Topology, final Properties props, final KafkaClientSupplier clientSupplier) 
public KafkaStreams(final Topology, final Properties props, final Time time)

Proposed Changes

We suggest to deprecate all the constructors using StreamsConfig, and use java.util.Properties instead.

Compatibility, Deprecation, and Migration Plan

  • What impact (if any) will there be on existing users?
  • If we are changing behavior how will we phase out the older behavior?
  • If we need special migration tools, describe them here.
  • When will we remove the existing behavior?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.

  • No labels