[ 
https://issues.apache.org/jira/browse/KAFKA-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chris Egerton updated KAFKA-9083:
---------------------------------
    Description: 
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]}}{{}}
 * 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.

  was:
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]}}{{}}
 * 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.


> 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
>            Priority: Major
>
> 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]}}{{}}
>  * 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)

Reply via email to