Archives for September2013

Embed Vert.x eventbus into your Spring Application with ease.

So, Vert.x 2.0+ now makes it so easy to embed Vert.x into any application. In our case, we wanted to embed Vert.x in a Spring MVC Rest Web Application, so that we can send messages from the Web Application to the eventbus to be picked up by our Vert.x application. All these messages are to be sent from the server side, which is why we did not simply choose to use Vert.x in our client side JavaScript, which is also very easy to do. We actually wanted the sending calls to be done by the back end Services, not even the Controllers of the web app. You know server side services that are re-usable. 😉

Anyway, using Vert.x documentation (Yes, you can learn this from the docs too), I found that it was extremely easy.

Biggest challenge was making sure the correct Vert.x jars are in your classpath of your web application. If you are using Maven, we simply added


        <!-- Vert.x jars to be included-->
        <dependency>
          <groupId>io.vertx</groupId>
          <artifactId>vertx-core</artifactId>
          <version>${vertx.version}</version>
          <exclusions>
              <exclusion>
                  <groupId>log4j</groupId>
                  <artifactId>log4j</artifactId>
              </exclusion>
          </exclusions>
        </dependency>
        <dependency>
          <groupId>io.vertx</groupId>
          <artifactId>vertx-platform</artifactId>
          <version>${vertx.version}</version>
        </dependency>

Those dependencies will pull in other dependencies too. Here is the mvn dependency:tree output for those two dependencies

+- io.vertx:vertx-core:jar:2.0.0-final:compile
[INFO] | +- com.fasterxml.jackson.core:jackson-databind:jar:2.2.2:compile
[INFO] | | \- com.fasterxml.jackson.core:jackson-annotations:jar:2.2.2:compile
[INFO] | +- com.fasterxml.jackson.core:jackson-core:jar:2.2.2:compile
[INFO] | +- com.hazelcast:hazelcast:jar:2.5:provided (version managed from 2.6; scope managed from compile)
[INFO] | \- io.netty:netty-all:jar:4.0.2.Final:compile
[INFO] \- io.vertx:vertx-platform:jar:2.0.0-final:compile

Then for getting the EventBus in our code, we wanted to be able to simply @Autowire into any class that we wanted. So we used an @Configuration class that instantiates Vertx and gets the EventBus from it as an @Bean.

Simple as


@Configuration
@PropertySource(value="classpath:vertx.properties")
public class OurAppConfiguration.class {

  private static final String VERTX_HOSTNAME = "vertx.hostname";

  @Autowired
  Environment environment;

  @Bean
  public EventBus eventBus() {
    Vertx vertx = VertxFactory.newVertx(environment.getProperty(VERTX_HOSTNAME));
    return vertx.eventBus();
  }
}

So as you can see we have a vertx.properties file with one property in it. You can, of course, add more properties, like port number and such. But just remember to add that to the call to VertxFactory.newVertx. As we do in the first line of the @Bean method. And just return vertx.eventBus(). Easy as pie.

Remember if you want this EventBus to work with another Vert.x application running somewhere else within your network, to run that one with -cluster, so that clustering works (If you need clustering)

To test this out, we wrote a simple JUnit Test with Spring integrated into it. Here is the code.


// YOU MUST BE RUNNING other Vert.x application with -cluster to run this test.
@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(classes=[OurAppConfiguration.class])
class TestVertxEventBus {

  @Autowired
  EventBus eventBus

  @Test
  public void testSendingMessageOnEventBusToOtherVertxApplicationHelloWorld() {
    CountDownLatch startSignal = new CountDownLatch(1);
    eventBus.send("test.address", sendMessage, new Handler<Message<String>>(){
        void handle(Message<String> message) {
          assertNotNull(message)
          String response = message.body()
          assertEquals("Well Hello back", response)
          startSignal.countDown()
        }
      }
    )
    startSignal.await()
  }
}

I had to alter some of the code because it was specific to our application, which I am not at liberty to post. But you should be able to make an extremely simple Verticle that listens to the eventBus at “test.address” and responds back. Simple echo, or request-reply works. Vert.x has that in the examples right up front.

So I am not going to post one here. I’ll just say, if you don’t know how to write a real simple Verticle, then don’t try to embed Vert.x in another application just yet. While it is really easy to do, it is still and advanced Vert.x topic

As always, don’t even try to post spam that tries to look like a real response. It is too easy to see and they will never get onto this page.

Converting your Vert.x 1.x module to Vert.x 2.x

In this post, I am going to list the number of things we needed to do in order to upgrade our application/modules to Vert.x 2.0.

It is more a list than prose, because I need to create this post as I go along the ride. Because I am sure I will forget something that I did, if I do this post-mortem (Is that the correct way to use that term, or is it supposed to be something else.

1) Make sure all your modules match the module naming standard. Vert.x 2.0 will not run your module unless it matches. It has code to catch it immediately.
2) You probably want to upgrade your build to Gradle, since the Gradle template starts things off nicely. This can be very difficult if you are currently using Maven and have lots of dependencies. You will need to add all those dependencies to the gradle.build file. Which is why at this point we haven’t done it yet, I converted my Maven build to a better Maven pom based on Vert.x Maven Archetype. (see paragraph after next)

Another Gradle recommendation is move all the versioning of dependencies into the gradle.properties file.

Option – If you are converting your application that is currently in Maven, and you want to jump to Gradle. First recommendation, don’t. At least not at first, get your application upgraded to Vert.x 2.0, which requires changes to your Maven pom files (Could be lots of different one). Then once you have it working, then look at converting your maven build to Gradle.

For all the build stuff, the approach I took to change our maven pom file was to create a test Vert.x 2.0 project from the new Vert.x maven archetype. Then look at the pom file it creates and basically copy and paste things. Now each project that you have to update, might need different things changed, removed or added. However, really try to get your pom file to match the pom file that that archetype created.

With Vert.x 2.x you will also really want to take advantage of the testtools jar file as it has now become really easy to write Vert.x eventbus integration tests with TestVerticle. I might create a blog post just on that subject later. One that includes writing the integration tests as well as how you can use a TestVerticle to fire off your Vert.x appication within an IDE.

Overall, I would say those are the two main factors to watch out for. 1) naming of your modules and 2) Bigger issue to update your build files. As far as any code changes, there really shouldn’t be any.