Vert.X in IntelliJ IDEA

Well, that was fast. Outdated within minutes of posting 🙂
This post is for vert.x 1.3.1. 

I just wrote an update on how to do this with vert.x 2.0.0.final


I took a look at Disruptor back when it was released. It was an interesting piece of software but I never got beyond playing around. Then came Node.js. I have been fighting with myself for quite a while to use it but I am kind of biased when it comes to JavaScript… Well, then came vert.x and I finally had no excuse left to get into this single-threade-thingy-stuff. Playing around with vert.x was quite a fun experience I will write about later. Today I want to show you how to get it running in my favorite IDE.

The Problem

Being polyglot apparently also means to abandon tested deployment strategies. So instead of dumping a JAR/WAR or whatever else into the vert.x-container you will have to do some special magic. And this special magic also involves some tinkering with Idea.

Basic Project

The following (very basic) build.gradle gives you a simple vert.x project.

apply plugin:'java'

configurations {
    provided
    provided.extendsFrom(compile)
}

repositories {
    mavenCentral()
    mavenLocal()
    mavenRepo url: "https://repository.apache.org/content/repositories/snapshots/"
    mavenRepo url: "http://source.mysema.com/maven2/releases/"
    mavenRepo url: "http://repo.maven.apache.org/maven2"
}

dependencies{
        compile "org.vert-x:vertx-core:1.3.1.final"
    compile "org.vert-x:vertx-lang-java:1.3.1.final"
    compile "org.vert-x:vertx-platform:1.3.1.final"
}

Import it and add a vertical like the following:

package de.codepitbull.vertx;

import org.vertx.java.core.Handler;
import org.vertx.java.core.http.HttpServerRequest;
import org.vertx.java.deploy.Verticle;

import java.util.Map;

/**
* @author Jochen Mader
*/
public class HttpVerticle extends Verticle{
@Override
public void start() throws Exception {
vertx.createHttpServer().requestHandler(new Handler() {
public void handle(HttpServerRequest req) {
StringBuilder sb = new StringBuilder();
for (Map.Entry<String, String> header : req.headers().entrySet()) {
sb.append(header.getKey()).append(": ").append(header.getValue()).append("\n");
}
req.response.putHeader("content-type", "text/plain");
req.response.end(sb.toString());
}
}).listen(8087);
}
}

And, due to a bug in 1.3.1, you also need to add a langs.properties to your project with the following content:

java=org.vertx.java.deploy.impl.java.JavaVerticleFactory
class=org.vertx.java.deploy.impl.java.JavaVerticleFactory
js=org.vertx.java.deploy.impl.rhino.RhinoVerticleFactory
coffee=org.vertx.java.deploy.impl.rhino.RhinoVerticleFactory
rb=org.vertx.java.deploy.impl.jruby.JRubyVerticleFactory
groovy=org.vertx.groovy.deploy.impl.groovy.GroovyVerticleFactory
py=org.vertx.java.deploy.impl.jython.JythonVerticleFactory
default=org.vertx.java.deploy.impl.java.JavaVerticleFactory

Setup

To get this whole thing running you will need to download the vert.x tar and untag it to your file system. Next select File>New Module and create a new Java-Module using the wizard. After you are done open Open Module Settings and select your newly created module. Go to the Dependencies-tab and add the content of your vert.x-installations lib-directory. Next add the folder containing langs.properties. Almost there.

Shows the dependency screen in idea with all required deps added.

Start Config

Now that we got our little dummy-project up and going we need to create a start config. So create a new Application-Startconfig. – Set the Main-class to org.vertx.java.deploy.impl.cli.Starter – Set Program arguments to run de.codepitbull.vertx.HttpVerticle -cp where the path is the place where Idea puts your compiled classes from the gradle-project. – Set Use class path of module to the module we just configured. That’s it.

Shows the filled fields as described in the text.

Hit run and go to home sweet home

Advertisements

Serving static content with Jetty 9

I am currently (again) doing a lot of JavaScript related stuff. My favorite IDE (IntelliJ IDEA) has stellar support for this crappy language. The only thing I needed was a SMALL web server to play around with static html and some JavaScripts. The quickest way was to use Jetty 9 as it can be found on all of my development machines.

Just add a Jetty9-RunConfig in IDEA (or Eclipse, if you have to) and create static.xml with the following content in $JETTY_HOME/webapps.

<?xml version="1.0"  encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.eclipse.org/configure.dtd">

<Configure class="org.eclipse.jetty.server.handler.ContextHandler">
  <Set name="contextPath">/static</Set>
  <Set name="resourceBase">/path/to/your/document/root/</Set>
  <Set name="handler">
    <New class="org.eclipse.jetty.server.handler.ResourceHandler">
      <Set name="cacheControl">no-cache</Set>
    </New>
  </Set>
</Configure>

Don’t forget to adjust resourceBase to your liking.

Note: I also disabled caching in this example.

I love Open Source

So, while being on parental leave I didn’t really have time for coding.
I decided to pick up a book on scala to read between changing diapers and cooking for my wife.
Naturally I didn’t really get the time to look into the scala book until the very end of my leave.
When I started to read the book I realized the need o have some pet project.
Having worked with the jmonkey 3d engine before I decided to give it a shot and set up a small project in maven.
Going to their homepage I was completely blown away by the progress they had made since the last time I worked with the engine (Note: At the time I switched companies they had lost their lead dev).
The engine looks very polished and got a good set of tools to work with.
After poking around in the demos for a while I tried getting a scala project going. The only problem was the lack of maven support.
So after posting on their forum to get some infos on the state of maven support it became clear that the core devs had no intentions to provide it.
But people started talking about implementing it on their own. Somebody had already done some work and we decided to do a project to get things going.
People provided their code, the jme-devs got us some git-space and I got the nexus-repo.
Today I submitted the final fixes and we now got full maven support including archetypes.
I love open source and the mentality of cooperation behind it.
Just saying.

P.S.: Still didn’t have time to start the scala book but the stage is set.

I demand answers to save OSGi

Adam Biehn’s blog is quite an interesting read. But I almost missed a very interesting post there.
Why I almost missed it? Cause I am sick of all those pointless OSGi vs Jigsaw discussions.
After reading the title “How To Kill An OSGi Project – With 10 Questions” I almost skipped it, expecting another piece of flamebait.
Thankfully I read it and I have to admit: He got some good points there.
The set of questions is something each developer/architect should go through before getting started with modularization.

The only thing I don’t like about this article:
Why on earth formulate GENERAL modularization problems in a way to make them look like they were exclusive to OSGi? I know, objective is long lost in the whole modularity discussion, but come on.

So here is my 100% subjective take on his questions:

1. What is your versioning scheme for modules(bundles)? Do you care about minor versions, major versions etc?

This debate has been going on forever. I use major.minor.patch for version, something OSGi has been doing for ages, tons of open source projects do it and I never had any real problems with it. As long as nobody shows me REAL advantage of other versioning schemes I’ll keep using it.

2.  What’s your scm strategy – do you plan to open and maintain a branch for every version of a module? How many branches do you plan to maintain? (with svn? :-))

As soon as something is deployed to the external world it gets a branch.
Yes, the amount of branches you are ending up with is big.
When thinking about modularity this is something you can’t ignore as this adds significant project overhead.
Once again: I just don’t see why this is an OSGi problem. Every modularization system will introduce this problem. If you are not prepared to deal with it, don’t modularize.

3. How many versioned modules will be active at the same time in production?

Best case: 1

Worst case: ∞

App servers have been doing this for ages. They allow deployment of several application instances with different versions (Captain Obvious strikes again, I know). The key thing here is that vendors have been reinventing the wheel for this countless times.
OSGi (and other modularization frameworks) provide the means to handle these situations in a generic way.
Another scenario can be summed up in one word: Drivers.
A lot of time we need to provide connectivity something outside our world.
These things are constantly changing. Sometimes a firmware upgrade is enough to make a driver useless.
From a company point of view it is a valid thing to increase the major version, remove support for the old firmware and carry on with a clean bundle.
Nice move, the customers will just upgrade all their hardware to the new firmware and carry on using the new driver. How long can it possibly take to upgrade 200 RFID readers to the newest version … I think you understand the problem.

The capability of having the same thing deployed multiple times in different versions is something that won’t be needed for most enterprise apps. But it’s good to know that the functionality is out there. Just don’t think you are getting it for free.

4. How the system is going to be tested? Each module and all the combination of modules. Every version will increase the complexity significantly.

Unit testing just doesn’t cut it for a real modular system.
“Each module and the combination of modules”, I’d even add another part ” and all their versions”.
Looking back at my answer to question 2 the problem becomes apparent.
Over time it becomes utterly impossible to test all combinations. Writing Unit tests and testing them will actually start eating up more time as the development of the whole application.
My suggestion: Use “Design by Contract
The main problem of modularity in Java is Javas inherent lack of true contracts. Interfaces are the weakest type of contracts in OO. I actually wouldn’t even call them contracts but suggestions, like traffic lights in New York.
To make a modular system more robust one needs to define real contracts and check if the bundle follows the previously defined contract.
The contracts need to cover both: exported services and api.
Get Contract4J or use some AspectJ and annotations to define the contracts. Combined with unit tests for each bundle this should give a lot better ratio of test
This isn’t a 100% solution and I fully agree that a lot more has to be done in the area of testing. But we are just now seeing how modularization technologies are getting into the mainstream and I guess there’s going to be a lot of development in that direction.
So far I think the combination contracts and unit testing is already a pretty good start.

5. What is your release-management strategy? Do you really plan to provide customer-specific module combinations? What is your bug-fixing / patch strategy (trunk, branch)?

Ok, here I just can’t give a generic answer as this strongly depends on the project you are doing and has to be decided on per project basis.

6. Do you really want to replace modules in running system? If it is a serverside system – what happens with in-flight transactions?

The question shouldn’t be if you want to, but if you have to. Sticking to the good all KISS principle should give you the right answer to this one. If you don’t need it, don’t use it. I needed it, I used it, I developed a strategy to deal with problematic scenarios, it worked. It’s not easy, but software architecture isn’t either.

7. If it is an Eclipse-RCP application – are you even allowed to expose the plugins to the end-user? (in the majority of my projects, we had to disable the update manager in production :-))

Sorry, never had to deal with such a scenario. Skipping this one.

8. What is your software distribution system – many companies have already a software-distribution system in place. Often not only the application, but also the JVM are packaged into one binary file and entirely installed. Incremental updates are often impossible.

Ok, so far you answered all questions in favor of modularity. Your customer loves it but REALLY wants to stick with his software distribution system without wanting to compromize. Cool, you just killed the project.
How often did you have to deal with a customer who desperately wanted to stick with JDK 1.2 or a good old Oracle 8.x installation?
That’s just how it goes …

9. What is exactly the contract between the modules? Only a Java-Interface? If so – what to do with direct relations between JPA-entities. If you disallow direct JPA-relations – you will probably see a huge „domain“ package with all domain objects inside it. You will need to provide „friend“ relations between modules as well.

I guess you know my answer: Design by Contract (see question 4).
With friend relations I guess he means Bundle-BuddyPolicy and I can’t see anything wrong with that. I avoid it if I can but sometimes it’s the best solution for the problem at hand.

10. Is maven the canonical representation of modules, OSGi, or both? A single representation would be the best. Will maven module versions be reflected in the OSGi bundle versions?

Maven … OSGi … Maven
Maven module versions should reflect the bundle version. The problem is that mostly you will be doing it the other way round as people will often create the MANIFEST.MF from the pom.
My wish: OSGi should be the canonical representation.
The reality: Maven module versions are the canoncial representation.
With Tycho hopefully getting a stable release within the next month and Sigil finalizing their transition to Felix things might finally start changing.

So, here you go. A completely subjective list of answers.
I had a little rant prepared about what I don’t like about his way of formulating the questions.
In the end I am just sick about pointless discussions.
Just get me some modularity into the JDK so I can kick out libraries I don’t need. Anything above will be OSGi. A least that’s what everybody else seems to do.