I responded to Ewen's suggestions in the PR and went back to using
ConfigException.
If I don't hear any other concerns today, I'll start a [VOTE] thread for
the KIP.
On Mon, Oct 30, 2017 at 9:29 PM, Ewen Cheslack-Postava
wrote:
> I took a quick pass at the PR, looks good so far. ConfigException
I took a quick pass at the PR, looks good so far. ConfigException would
still be fine in the case you're highlighting as it's inside the framework
anyway and we'd expect a ConfigException from configure() if connectors try
to use their ConfigDef to parse an invalid config. But here I don't feel
str
I've updated the KIP to use the topics.regex name and opened a WIP PR with
an implementation that shows some additional complexity in how the
configuration option gets passed through, affecting various public function
signatures.
I would appreciate any eyes on that for feedback on whether more des
I added a note in the KIP about ConfigException being thrown. I also
changed the proposed default for the new config to empty string rather than
null.
Absent a clear definition of what "common" regex syntax is, it seems an
undue burden to ask the user to guess at what Pattern features are safe. If
It's fine to be more detailed, but ConfigException is already implied for
all other config issues as well.
Default could be either null or just empty string. re: alternatives, if you
wanted to be slightly more detailed (though still a bit vague) re:
supported syntax, you could just say that while
bq. Users may specify only one of 'topics' or 'topics.pattern'.
Can you fill in which exception would be thrown if both of them are specified
?
Cheers
On Thu, Oct 26, 2017 at 6:27 PM, Jeff Klukas wrote:
> Looking for feedback on
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-
> 215%
Looking for feedback on
https://cwiki.apache.org/confluence/display/KAFKA/KIP-215%3A+Add+topic+regex+support+for+Connect+sinks
