[
https://issues.apache.org/jira/browse/KAFKA-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Randall Hauch updated KAFKA-9083:
---------------------------------
Fix Version/s: 2.4.1
2.3.2
2.5.0
2.2.3
> Various parsing issues in Values class
> --------------------------------------
>
> Key: KAFKA-9083
> URL: https://issues.apache.org/jira/browse/KAFKA-9083
> Project: Kafka
> Issue Type: Bug
> Components: KafkaConnect
> Reporter: Chris Egerton
> Assignee: Chris Egerton
> Priority: Major
> Fix For: 2.2.3, 2.5.0, 2.3.2, 2.4.1
>
>
> There are a number of small issues with the Connect framework's {{Values}}
> class that lead to either unexpected exceptions, unintuitive (and arguably
> incorrect) behavior, or confusing log messages. These include:
> * A {{NullPointerException}} is thrown when parsing the string {{[null]}}
> (which should be parsed as an array containing a single null element)
> * A {{NullPointerException}} is thrown when parsing the string {{[]}} (which
> should be parsed as an empty array)
> * The returned schema is null when parsing the string {{{}}} (instead, it
> should be a map schema, possibly with null key and value schemas)
> * Strings that begin with what appear to be booleans (i.e., the literals
> {{true}} or {{false}}) and which are followed by token delimiters (e.g., {{},
> {{]}}, {{:}}, etc.) are parsed as booleans when they should arguably be
> parsed as strings; for example, the string {{true}}} is parsed as the boolean
> {{true}} but should probably just be parsed as the string {{true}}}
> * Arrays not containing commas are still parsed as arrays in some cases; for
> example, the string {{[0 1 2]}} is parsed as the array {{[0, 1, 2]}} when it
> should arguably be parsed as the string literal {{[0 1 2]}}
> * An exception is logged when attempting to parse input as a map when it
> doesn't contain the a final closing brace that states "Map is missing
> terminating ']'" even though the expected terminating character is actually
> {{}}} and not {{]}}
> * Finally, and possibly most contentious, escape sequences are not stripped
> from string literals. Thus, the input string
> {{\{foo\\bar\]}} is parsed as the literal string
> {{\{foo\\bar\]}}, which is somewhat unexpected, since
> that means it is impossible to pass in a string that is parsed as the string
> literal {{{foo\bar]}}, and it is the job of the caller to handle
> stripping of such escape sequences. Given that the escape sequence can itself
> be escaped, it seems better to automatically strip it from parsed string
> literals before returning them to the user.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
