Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

KafkaConsumer consumer = new KafkaConsumer("(localhost:9999,;localhost2:99999);parameter1=value2;parameter2=value3", new ByteArrayDeserializer(), new ByteArrayDeserializer());

...

  • As mentioned above, there would be an addition to KafkaConsumer, KafkaProducer and KafkaAdminClient
  • An utility class will be added to map the string parameters to current configurations. That constructor would then delegate to the already existing code.

 

Format

My proposed format for the connection string would be:

(host1:port1,;host2:port2,);…host:portn;param-name1=param-val1,;..param-nameN=param-valN

 

Invalid conversions would throw InvalidArgumentException (with a description of the invalid conversion)


  • the first parameter should be a list of connections and ports in parenthesis
  • The other parameters will be separated by semi-colon ( ; )

Values and Escaping

  • Strings are bound by regular single quotes (') or double quotes (")
    • This is because this would make the syntax easier for when writing constants.
  • Parameters are separated by ;
  • the first parameter should be send between parenthesis, as there's usually a list of connections
  • A back slash (\) will make the next character a regular constants. You can use these valid combinations
    • \\ meaning a regular \
    • \" meaning a literal "
    • \$ meaning a literal $
    • \; is reserved to be used as a literal colon. Its usage won't be necessary if inside strings.
  • $$ will also mean literal $

It should be possible to use \ to introduce either ; or " as part of the parameters

$Arguments

  • $ Arguments will be translated as the System property defined.
  • Example: user=$userID will be translated as the system property "userID"

Error Handling

Typos will be informed with a log.warn. This is to avoid moving back and forth to versions where the parameter is not supported. We had a discussion on the dev list and it was suggested we should just ignore invalid parameters to avoid version compatibility issues.

For invalid encoding (things like string open), the implementation should throw an InvalidArgumentException informing the syntax errorInvalid parameters would throw InvalidArgumentException (with the name of the invalid parameter).

Compatibility, Deprecation, and Migration Plan

...