[
https://issues.apache.org/jira/browse/KAFKA-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16959174#comment-16959174
]
ASF GitHub Bot commented on KAFKA-9083:
---------------------------------------
C0urante commented on pull request #7593: KAFKA-9083: Various
fixes/improvements for Connect's Values class
URL: https://github.com/apache/kafka/pull/7593
[Jira](https://issues.apache.org/jira/browse/KAFKA-9083)
The following functional changes are implemented here:
• Top-level strings beginning with `"true"`, `"false"` and then followed by
token delimiters (e.g., `"true}"` and `"false]"`) are parsed as strings, not as
booleans
• The empty array (`"[]"`) is now parsed as an array with a null value schema
• The empty map (`"{}"`) is now parsed as a map with null key and value
schemas
• Arrays with all-null elements are now parsed successfully (whereas before
an NPE was thrown) as an array with a null value schema
• Maps with all-null values are now parsed as maps with null value schemas,
but non-null key schemas
• Strings that appear to be arrays at first but are missing comma delimiters
(e.g., `"[0 1 2]"`) are now parsed as strings instead of arrays
• A small improvement is made to the debug message generated when map
parsing fails due to unexpected comma delimiters ("Unable to parse a map entry
has no key or value" is changed to "Unable to parse a map entry with no key or
value")
• A small improvement is made to the debug message generated when map
parsing fails due to a missing `}` ("Map is missing terminating ']'" is changed
to "Map is missing terminating '}'")
• A small improvement is made to the debug message generated when array or
map parsing fails and parsing is reset to process the input as a string
("Unable to parse the value as a map" is changed to "Unable to parse the value
as a map or an array")
• Embedded values that lack surrounding quotes (e.g., `foo` in `"[foo]"`)
are no longer treated as strings; this is in line with the JSON-like
representation that is meant to be supported by the `Values` class and prevents
errors such as parsing `"[0 1 2]"` as an array containing a single string
element with a value of `"0 1 2"`
• The top-level string `"null"` is now parsed as `null` instead of the
string `"null"`; this does not break attempts to convert the top-level string
`"null"` into a string (which should also be the string `"null"`)
Every change (except for log message alterations) is verified with one or
more unit tests, and several unit tests are also added to prevent regression in
functionality that, while not currently broken, is subtle enough that it may be
missed in future changes without tests.
### Committer Checklist (excluded from commit message)
- [ ] Verify design and implementation
- [ ] Verify test coverage and CI build status
- [ ] Verify documentation (including upgrade notes)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> 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]}}
> * 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)
