kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manikumar (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (KAFKA-3571) Traits for utilities like ConsumerGroupCommand
Date Sun, 01 Jul 2018 13:22:00 GMT

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

Manikumar resolved KAFKA-3571.
------------------------------
    Resolution: Won't Fix

Now AdminClient has support for most of the admin API. This can be used for testing tools
or building various utilities.  Please reopen if you think otherwise.


> Traits for utilities like ConsumerGroupCommand
> ----------------------------------------------
>
>                 Key: KAFKA-3571
>                 URL: https://issues.apache.org/jira/browse/KAFKA-3571
>             Project: Kafka
>          Issue Type: Improvement
>          Components: clients
>    Affects Versions: 0.9.0.1
>            Reporter: Greg Zoller
>            Assignee: Liquan Pei
>            Priority: Minor
>
> I notice that several utilities like ConsumerGroupCommand are implemented (hard-wired
really) to be command-line utilities.  It'd be really handy for testing if these were broken
out as Scala traits (that don't call println) with the concrete classes or objects being the
command-line utility.
> As a trait I could create a thin wrapper class passing the same array of arguments, and
instead of producing screen output the trait could produce result classes.  
> The command-line utilities (your concrete classes implementing the traits) could format
screen output from the result classes.
> Why do this?  It'd be a really nice way for test code to query things like offsets and
such after a test run.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message