This version (2017/05/27 13:44) is a draft.
Approvals: 0/1

[08:29:40] <cescoffier> jtruelove : why not a simple Main class, extending Launcher and configuring the options in the `beforeStarting` callback ?

[17:07:23] * ChanServ sets mode: +o temporalfox [19:00:35] <jtruelove_> temporalfox which project is the CLI Launcher in? core or somewhere else that you suggest extending? [19:00:43] <temporalfox> core [19:40:52] <jtruelove_> and is there an example of doing this anywhere? [19:52:28] <jtruelove_> beyond the tests that's any sample projects doing it this way? temporalfox ^ [20:50:47] <jtruelove_> is there a way to get the config object when you're in the method beforeStartingVertx [20:51:11] <jtruelove_> because to configure say vertx opentsdb i need the config i'm passing to the server [22:05:59] * ChanServ sets mode: +o temporal_

[22:15:53] <jtruelove_> temporal_ is there a way to get to the config object in the beforeStartingVertx block because apart from doing that I'm going to have capture the command line args and parse the file myself to get the config i need from it to configure vertx-opentsdb just seems kinda dirty given that the config has already been parsed is RunCommand before calling me

[22:18:52] <temporal_> jtruelove_ can you ask clement ? he's the cli wizard

[22:19:56] <temporal_> I can have a look now

[22:20:07] <temporal_> what base command are you looking at ?

[22:20:31] <jtruelove_> run but i think i'm wrong

[22:20:37] <temporal_> there is

[22:20:38] <jtruelove_> i just stepped through the code

[22:20:40] <temporal_> protected MetricsOptions getMetricsOptions() {

[22:20:46] <temporal_> that allows you to override the metrics options used

[22:21:01] <jtruelove_> i get that part and that is all great

[22:21:02] <temporal_> is it what you are looking for ?

[22:21:46] <jtruelove_> my issue is that when you get the call to 'beforeStartingVertx' the -conf parameter “hasn't” been parsed yet

[22:22:03] <jtruelove_> meaning if you need conf data in that file to configure something you don't have it yet

[22:22:16] <temporal_> which file ?

[22:22:21] <temporal_> ah conf.json

[22:22:24] <jtruelove_> yes

[22:22:44] <jtruelove_> even if it had been parsed VertxOptions doesn't give it to you

[22:23:14] <temporal_> when is it parsed ?

[22:23:23] <jtruelove_> in RunCommand the which kicks it all off happens before JsonObject conf = getConfiguration();

[22:24:11] <temporal_> ah ok yes

[22:24:16] <temporal_> so what I would do if I were you

[22:24:20] <temporal_> I add a new option

[22:24:26] <temporal_> on your command

[22:24:52] <temporal_> and I override run()

[22:25:06] <temporal_> and there you parse the conf-metrics if that exists

[22:25:08] <temporal_> you put it on the instance command

[22:25:17] <temporal_> I mean something like that

[22:25:22] <temporal_> it looks like it would be doable

[22:25:30] <temporal_> other option is to parse conf twice

[22:25:38] <jtruelove_> yeah i mean i could also just do that

[22:25:48] <jtruelove_> which feels dirty but whatever

[22:25:52] <temporal_> you could call getConfiguration() before run()

[22:25:54] <temporal_> I think

[22:26:06] <temporal_> it seems flexible enough

[22:26:10] <jtruelove_> i was wondering that

[22:26:40] <jtruelove_> and change run to take the a JsonObject? or some stick it on VertxOptions?

[22:26:52] <jtruelove_> somehow i meant

[22:28:07] <jtruelove_> or just expose it on the command i guess, getConfig

[22:31:29] <jtruelove_> hmm but you have that, you could add a hook for config parsed

[22:31:42] <jtruelove_> and you just get the callback

[22:32:06] <temporal_> I'm gonna go jeremy :-)

[22:32:21] <jtruelove_> alright i'll ponder it

[22:32:27] <jtruelove_> you might get a pull request :p

[22:32:59] <temporal_> k