jkosh44 commented on a change in pull request #1083: [WIP] POC for Command
module with centralized Command Pattern logic
URL: https://github.com/apache/fluo/pull/1083#discussion_r357929289
##########
File path: modules/command/src/main/java/org/apache/fluo/command/FluoList.java
##########
@@ -18,18 +18,18 @@
import java.util.Collections;
import java.util.List;
+import com.beust.jcommander.Parameters;
import org.apache.curator.framework.CuratorFramework;
import org.apache.fluo.api.config.FluoConfiguration;
import org.apache.fluo.core.client.FluoAdminImpl;
import org.apache.fluo.core.util.CuratorUtil;
-public class FluoList {
+@Parameters(commandDescription = "Lists all Fluo applications in Fluo
instance")
+public class FluoList extends ConfigCommand {
- public static void main(String[] args) throws Exception {
-
- ConfigOpts commandOpts = ConfigOpts.parse("fluo list", args);
+ public void list() {
FluoConfiguration config = CommandUtil.resolveFluoConfig();
- commandOpts.overrideFluoConfig(config);
+ overrideFluoConfig(config);
Review comment:
So it seems like the pattern for resolving the config is as follows
First `CommandUtil.resolveFluoConfig()` is called which gets the config from
the file defined by the fluo.conn.props System property.
Then just the `FluoInit` class lets you override configs through a file with
the -p option
Then if the command extends AppCommand it will let you override the
application name via the -a option
Then it will override all the configs that you provide via the -o option.
The only exception is that FluoExec is structured differently than the other
commands, so I'll leave it out of this specific discussion.
I think it would make sense to give `ConfigCommand` the following method
```
FluoConfiguration getConfig() {
FluoConfiguration config = CommandUtil.resolveFluoConfig();
overrideFluoConfig(config);
return config;
}
```
and five `AppCommand` the following method
```
@Override
FluoConfiguration getConfig() {
FluoConfiguration config = super.getConfig();
config.setApplicationName(applicationName);
return config;
}
```
The only issue with this is that the order of overriding configurations may
change. This would only be an issue if someone is overriding configurations in
different places with different values. For example if someone gave an
application name via the -a option but then gave a different application name
via the -o option. I don't think this is really a valid use case so we should
be fine.
----------------------------------------------------------------
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]
With regards,
Apache Git Services
