[
https://issues.apache.org/jira/browse/KAFKA-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14051790#comment-14051790
]
Michael Noll commented on KAFKA-1519:
-------------------------------------
Supporting an empty value is of course another option. That's fine with me,
too.
That said I'm not sure whether it's actually more intuitive (it feels similar
to special-purposing "null" instead of returning "None"), but I'm a small
sample size. :-)
I'd have two questions:
* Where would one find unit tests, as Gwen mentioned, for the command line
parsing? I did a quick grep search of the code* but found none.
* Would this approach (support empty value) break any backwards compatibility?
This is difficult to answer for me without more intimate code knowledge and
because there don't seem to be any unit tests yet, see above.
*grep'ed with:
{code}
$ find . -type f | xargs grep parseKeyValueArgs
./core/src/main/scala/kafka/tools/ConsoleConsumer.scala: val formatterArgs =
CommandLineUtils.parseKeyValueArgs(options.valuesOf(messageFormatterArgOpt))
./core/src/main/scala/kafka/tools/ConsoleProducer.scala: val cmdLineProps =
CommandLineUtils.parseKeyValueArgs(options.valuesOf(propertyOpt))
./core/src/main/scala/kafka/tools/ReplayLogProducer.scala: val producerProps
= CommandLineUtils.parseKeyValueArgs(options.valuesOf(propertyOpt))
./core/src/main/scala/kafka/tools/SimpleConsumerShell.scala: val
formatterArgs =
CommandLineUtils.parseKeyValueArgs(options.valuesOf(messageFormatterArgOpt))
./core/src/main/scala/kafka/utils/CommandLineUtils.scala: def
parseKeyValueArgs(args: Iterable[String]): Properties = {
{code}
> Console consumer: expose configuration option to enable/disable writing the
> line separator
> ------------------------------------------------------------------------------------------
>
> Key: KAFKA-1519
> URL: https://issues.apache.org/jira/browse/KAFKA-1519
> Project: Kafka
> Issue Type: Improvement
> Components: consumer
> Affects Versions: 0.8.1.1
> Reporter: Michael Noll
> Assignee: Neha Narkhede
> Priority: Minor
>
> The current console consumer includes a {{DefaultMessageFormatter}}, which
> exposes a few user-configurable options which can be set on the command line
> via --property, e.g. "--property line.separator=XYZ".
> Unfortunately, the current implementation does not allow the user to
> completely disable writing any such line separator. However, this
> functionality would be helpful to enable users to capture data "as is" from a
> Kafka topic to snapshot file. Capturing data "as is" -- without an
> artificial line separator -- is particularly nice for data in a binary format
> (including Avro).
> *No workaround*
> A potential workaround would be to pass an empty string as the property value
> of "line.separator", but this doesn't work in the current implementation.
> The following variants throw an "Invalid parser arguments" exception:
> {code}
> --property line.separator= # "nothing"
> --property line.separator="" # double quotes
> --property line.separator='' # single quotes
> {code}
> Escape tricks via a backslash don't work either.
> If there actually is a workaround please let me know.
> *How to fix*
> We can introduce a "print.line" option to enable/disable writing
> "line.separator" similar to how the code already uses "print.key" to
> enable/disable writing "key.separator".
> This change is trivial. To preserve backwards compatibility, the
> "print.line" option would be set to true by default (unlike the "print.key"
> option, which defaults to false).
> *Alternatives*
> Apart from modifying the built-in {{DefaultMessageFormatter}}, users could of
> course implement their own custom {{MessageFormatter}}. But given that it's
> a) a trivial change to the {{DefaultMessageFormatter}} and b) a nice user
> feature I'd say changing the built-in {{DefaultMessageFormatter}} would be
> the better approach. This way, Kafka would support writing data as-is to a
> file out of the box.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
