Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make commands more easily reusable outside of CLI #1085

Open
jkosh44 opened this issue Jan 15, 2020 · 1 comment
Open

Make commands more easily reusable outside of CLI #1085

jkosh44 opened this issue Jan 15, 2020 · 1 comment

Comments

@jkosh44
Copy link
Contributor

jkosh44 commented Jan 15, 2020

In Issue #983 some people expressed a desire to be able to reuse commands outside of the CLI, for example in APIs and UIs. PR #1083 helped with this by removing System.exit from the commands themselves and restructuring the module so you don't have to call the main method on a command to execute it.

The following three issues still make it difficult for the commands to be reusable:

  1. Many of the commands directly print to System.out or log to a Logger.
  2. Many of the commands rely on side effects instead of returning a meaningful response (ex: FluoList, FluoStatus).
  3. There's no way to set the options of a command.
@jkosh44
Copy link
Contributor Author

jkosh44 commented Jan 15, 2020

Since the original issue, #983, is over 2 years old I thought this issue warranted a discussion to see if it's something people still want and if people agree with my proposed solution.
For 1 and 2, we can add a public method to the command classes that returns some type of data object (or primitive if applicable). Not all commands would need this additional method. execute() can call this method and do any necessary printing. APIs and UIs can use the public method. For example FluoStatus could look like this

@Parameters(commandNames = "status",
    commandDescription = "Prints status of Fluo application for <app>")
public class FluoStatus extends AppCommand {

  public enum AppStatus {
    NOT_FOUND, RUNNING, STOPPED
  }

  @Override
  public void execute() throws FluoCommandException {
    AppStatus appStatus = status();
    System.out.println(appStatus);
  }

  public AppStatus status() {
    FluoConfiguration config = getConfig();
    try (FluoAdminImpl admin = new FluoAdminImpl(config)) {
      if (!admin.zookeeperInitialized()) {
        return AppStatus.NOT_FOUND;
      } else if (admin.applicationRunning()) {
        return AppStatus.RUNNING;
      } else {
        return AppStatus.STOPPED;
      }
    }
  }
}

FluoWait and FluoInit will probably be a little tricky, especially since FluoInit can read input from System.in.

For 3 we can simply add setter methods for all the options.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant