Uploaded image for project: 'Kafka'
  1. Kafka
  2. KAFKA-9083

Various parsing issues in Values class

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.2.3, 2.5.0, 2.3.2, 2.4.1
    • Component/s: KafkaConnect
    • Labels:
      None

      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]
      • 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.

       

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                ChrisEgerton Chris Egerton
                Reporter:
                ChrisEgerton Chris Egerton
                Reviewer:
                Randall Hauch
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: