Clustering Embedded Vert.x with non-embedded Vert.x instances

[bytor99999]

Just asking to make sure, but this is the method we would call in the PlatformManagerFactory class to have this Vert.x instance cluster and share the eventBus with standard Vert.x instance run from the command line?

PlatformManager createPlatformManager(int clusterPort, String clusterHost);

Thanks

Mark

[Tim Fox]

On 14/06/13 19:16, bytor99999 wrote:
> Just asking to make sure, but this is the method we would call in the
> PlatformManagerFactory class to have this Vert.x instance cluster and share
> the eventBus with standard Vert.x instance run from the command line?

If you're embedding the Vert.x platform, yes.

If you're just embedding core then you'd use VertxFactory.

[bytor99999]

Thanks Tim. I think I want the platform. It will be a Java stand-alone application with Spring Framework with Spring Data and Spring Integration. But I want to inject the eventBus into my beans for setting up handlers as well as sending messages from this app to the eventBus.

Mark

[Tim Fox]

Cool.

BTW, now you are talking of Spring - are you going to submit a Vert.x
2.0 module that exposes the Spring Application Context?

[bytor99999]

I would love to. 

But I think there is still a ClassLoader issue. 

So now each Verticle Type gets its own classloader. 

Unless there is a parent classloader that I can use to get access to the Application Context and create a single instance of it, that all Verticle Types have access to. Then we would NOT be able to create a single ApplicationContext per Vert.x instance, which would be the ideal scenario.

So, in that case, the scenario of what I was doing about would work. Meaning create a Spring application and embed the platform. Which would not be a module, since Spring ends up around Vert.x rather than within Vert.x

Thanks

Mark

[bytor99999]

And I also will need to update our Vert.x application to use 2.0, since we still have it in 1.3.1, so that the two applications can share the eventBus, or downgrade HazelCast version in 2.0 (which I don't want to do)

Mark

p.s. Can you mow my lawn too? I forgot to do it this weekend.

[Tim Fox]

On 17/06/13 18:58, bytor99999 wrote:

I would love to. 

But I think there is still a ClassLoader issue. 

So now each Verticle Type gets its own classloader. 

Unless there is a parent classloader that I can use to get access to the 
Application Context and create a single instance of it, that all Verticle 
Types have access to. Then we would NOT be able to create a single 
ApplicationContext per Vert.x instance, which would be the ideal scenario.

Yes, you should be able do this, by putting it in a module and including it as I mentioned before.

Yes, there are parents. They're described here: http://vertx.io/vertx20_docs/mods_manual.html#module-classloaders

It should _just work_ (TM).

[bytor99999]

It is the morning, so maybe I am just really dense.

But reading the doc, it still seems that the class that is loaded is still contained within a module and cannot be shared single instance across all modules in a Vert.x instance.

There is the one part about not finding it so use the platform classloader, which seems to be where you can load the ApplicationContext from. But where to put the Spring jars in that context?

"If classes or resources cannot be found by any of the module class loaders in the hierarchy the platform class loader (i.e. the class loader that Vert.x itself uses) will be asked."

I guess from the command line you can add a classpath to point to the jars. Or is there a "lib" directory we can drop these in?

And then in the main app class where you do container.deployVerticle() you can deploy the upcoming Spring module.

Mark

[Tim Fox]

On 18/06/13 19:40, bytor99999 wrote:
> It is the morning, so maybe I am just really dense.
>
> But reading the doc, it still seems that the class that is loaded is still
> contained within a module and cannot be shared single instance across all
> modules in a Vert.x instance.

If you maintain your application context in a static member of a class
in a module, and you include that module in other modules then it will
indeed be the same application context instance which is seen by all
modules that include it.

>
> There is the one part about not finding it so use the platform classloader,
> which seems to be where you can load the ApplicationContext from. But where
> to put the Spring jars in that context?

The platform classloader is not relevant.

You would put the Spring jars in the lib directory of the spring module
that you're going to share

>
> "If classes or resources cannot be found by any of the module class loaders
> in the hierarchy the platform class loader (i.e. the class loader that
> Vert.x itself uses) will be asked."
>
> I guess from the command line you can add a classpath to point to the jars.
> Or is there a "lib" directory we can drop these in?
>
> And then in the main app class where you do container.deployVerticle() you
> can deploy the upcoming Spring module.

You don't need to deploy non runnable modules, you can include them
directly in other modules.

[Tim Fox]

If you can give me the code of the application context that you want to share (I don't know enough about Spring to do this myself) I can show you how to put it in a module as I describe.

[bytor99999]

OK that makes sense. a non-runnable module that creates an ApplicationContext whose instance is attached as a static member. Then include the module in any module that wants to use Spring.

Sounds cool. 

I'll start on it real soon. We have a deliverable on Friday, so this week is out. But next week for sure.

Mark