Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The uses of this library I've seen in our repos are compatible with the changes in this PR, and wouldn't require any code changes to update. But other users might have to make some small changes, so I'll release this as a new major version.
Changes:
There were several different ways to initialize ConsumerConfig, and they behaved differently. E.g. accepting/not accepting implicits, and initializing the default kinesis client using a different method. So you could get unexpected behavior when switching from one method to another. And there were other inconsistencies that were more of a usability issue, e.g. some values could be passed as params, but to set others you needed to use a builder-style copy method. So I changed things around to make them more consistent: (1) Moved all initialization and default logic into only two methods, apply and fromConfig, which behave the same way (both accept implicits, both initialize default clients with the same functions). The only difference is one reads certain values from a config, while the other has those values as params. (2) You can set any ConsumerConfig values using the params of these methods, so we no longer need the "with..." builder-style methods. (3) Moved configuration file reading into a separate object to keep it from getting mixed in with other initialization logic.
Changed the example configuration location in the readme (does not change behavior): Older configuration settings weren't added to the readme before, and need to be in a specific location. So some of our configurations ended up with two separate sections for the same consumer: one with the old settings, and one in the location that was copy-pasted from the readme for the new settings. So I just updated the example to include the old configs, and put the new ones in the same section so people won't end up with two different sections. (Two sections will still work, since the new configs can go anywhere and the location is passed manually.)