Vert.x Config chicken and egg issue?

[infor...@gmail.com]

Has anyone used Vert.x Config?

The Vertx constructor accepts a VertxOptions.  I would like those options to be configurable and retrieved via Vertx Config.

To create a ConfigRetriever however, I need a Vertx instance.

Do you see the circular dependency there?

It apparently works when I pass in "Vertx.vertx()" to ConfigRetriever, which would give me a different (and disposable) Vertx instance.

That seems fine except that I also would like my ConfigRetriever to listen for changes.  Underneath, it uses this same Vertx instance.  So it's not disposable after all.

Do you guys see any issues with me having two difference Vertx instances?  One for this periodic scan of the configuration stores and another for everything else in my application?

What are the implications of doing that?

Thanks!

Iggy (vert.x newbie, please be kind)

[infor...@gmail.com]

Oops, ...different* Vertx instances...

[infor...@gmail.com]

I guess I could create an initial ConfigRetriever just for the vertx options, use those options to create a new Vertx instance, and then create a subsequent ConfigRetriever using this new Vertx instance.  Problem solved.

If anyone has better ideas, please let me know.

[infor...@gmail.com]

The downside of course is that it'd be reading the config twice. Hopefully, the startup won't take too long as a result. It will matter to this application.

[infor...@gmail.com]

K, problem solved again.  I was forgetting the fact that I didn't have to call getConfig() on the second ConfigRetriever.  I can keep the JsonObject read by the first one.  Just need to set the periodic scan on the second one.

Pardon the soliloquy. Hope someone else finds this useful in the future.

[infor...@gmail.com]

Well, the ConfigRetrieverImpl constructor actually calls getConfig().  Had to create a subclass to override it. When the completionHandler is a Future, then it calls super.getConfig().  Otherwise, it does nothing. (The constructor passes an anonymous no-op handler, which is a good thing. I was able to use that as my indicator.)

IMHO, the constructor shouldn't be calling getConfig(). Constructors shouldn't do much in general.

Now my code has a reference to ConfigRetrieverImpl. Sigh.

Thanks!

Iggy

[Julien Viet]

Hi,

if you think that's an issue can you open an issue on GitHub ?

Julien

-- 
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at https://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/6c5739d0-5c63-4ee4-a49e-d6fc9fdefe77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clement Escoffier]

I agree that calling getConfig is tricky.I believe it can be dropped. It was useful at some point to cache the configuration ASAP. But I would consider this as an anti-pattern.

So please fill an issue.

Clement

To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/54B2F59D-FC79-424E-8E22-DFE5509C7668%40julienviet.com.

[infor...@gmail.com]

Thanks.  https://github.com/vert-x3/vertx-config/issues/23

[infor...@gmail.com]

Btw, meant chicken-or-egg, not chicken-and-egg. :)