Creating a second Vertx context + using Guice

[elect...@gmail.com]

In my App extends AbstractVerticle class's main() method, I create a first instance of Vertx using only one DeploymentOptions which is "guice_binder" from vertx-guice. Then, using this instance, I deploy the App class itself as a first Verticle.

The aim is that in the start() method of this first App Verticle, the Guice context is now loaded and I have access to my configurations (which are wrapped inside a custom class), injected by Guice. So I can now do some validation to see which DeploymentOptions to use for the "real" Vertx instance I need! For example :

VertxOptions vertxOptions = new VertxOptions();
if(myConfigsInjectedByGuice().getBoolean("environment.isDev")) {
    vertxOptions.setBlockedThreadCheckInterval(1000*60*60);
}
Vertx realVertx = Vertx.vertx(vertxOptions);

And then, using this new Vertx instance, configured correctly, I can create my other Verticles, which would then :

1) Have access to the configurations injected by Guice.

2) Use the second Vertx instance, configured correctly.


My questions :

- Are there some issues to look for when creating a second Vertx instance like this?

- I get this warning message in the console doing so : "You're already on a Vert.x context, are you sure you want to create a new Vertx instance?". Should I be worried?

- Would the first Vertx instance block some CPU's cores?

- Is there a better pattern to use Guice as soon as possible in a Vert.x app?

Thanks in advance!

[Paulo Lopes]

Guice should be a singleton otherwise your injected Beans are not guaranteed to be singletons.

The best idea is to have guice to be instantiated from the main method ```public static void main(String[] args)``` this way there shall be only one. However doing this you are to bootstrap vert.x yourself but apparently you're already doing that anyway. It also means that you loose the config since it will only be available once a verticle is instantiated (the start method) unless you have some lazy dependency injection.

[elect...@gmail.com]

Thanks for your help Paulo.

I actually chnaged the way I was doing the bootstraping, with your suggestions in mind. Here it is in case it can help someone. I just finished the code so I may still have to tweak one thing or two.

I only have one Vertx instance now...

App.java :

public static void main(String[] args) {
    Injector injector = Guice.createInjector(new GuiceModule());
    Vertx vertx = injector.getInstance(Vertx.class);
    WebServer webServerVerticle = injector.getInstance(WebServer.class);

    DeploymentOptions deploymentOptions = new DeploymentOptions();
    vertx.deployVerticle(webServerVerticle,
                         deploymentOptions,
            new Handler<AsyncResult<String>>() {
        @Override
        public void handle(AsyncResult<String> result) {
            if(result.failed()) {
                throw new RuntimeException("Error : " + result.cause());
            }
            logger.info("Verticle WebServer deployed");
        }
    });      
}

GuiceModule :

public class GuiceModule extends AbstractModule {

    @Override
    protected void configure() {
        bind(AppConfig.class).in(Scopes.SINGLETON);
        bind(WebServer.class).in(Scopes.SINGLETON);  
    }
   
    @Provides
    @Singleton
    protected Vertx vertxProvider(AppConfig appConfig) {

       
        VertxOptions vertxOptions = new VertxOptions();

        if(appConfig.getBoolean("environment.debug", false)) {
            vertxOptions.setBlockedThreadCheckInterval(1000*60*60);
        }
       
        Vertx verxt = Vertx.vertx(vertxOptions);
        return verxt;
    }
}

A limitation is that AppConfig can't use the Vertx instance or any other dependency which uses it...

Any idea to improve this would be welcome!

 

[elect...@gmail.com]

By the way, I don't use vertx-guice anymore, just plain Guice.

[jklingsporn]

Hi,

I'm using vertx together with the vertx-guice-module. However it has currently one caveat: the singleton-scope is bound to a vertx-instance so it might happen that you end up with x 'singletons' when you deploy x different vertx-instances (or set the instanceCount to x). I submitted a pull-request that allows you to use the same injector across all instances.

Link to the discussion: https://groups.google.com/forum/?fromgroups=#!topic/vertx/p-ZcfEy6Sp0

Link to the PR: https://github.com/englishtown/vertx-guice/pull/7

HTH,

Jens

[elect...@gmail.com]

Hi Jens,

Thanks for the information.

By the way, is there an advantage I don't see to use vertx-guice instead of a plain Guice solution as I suggest? I want to be sure I'm not missing something...