Today I want to talk about one of the younger members in the Eclipse family: Jetty. It is great to have such an interesting project on board and it is yet another example of how Eclipse has become more than just an IDE.

What I wanted to with jetty was to create an executable, standalone and self-contained WAR. I first encountered this concept in Hudson. The hudson.war contains an embedded Winstone servlet container, which makes it possible to run the application by executing

java -jar hudson.war

This makes test driving the application really simple. The idea was to do the same with Jetty. Embedding the Jetty runtime in the war proved to be the easy part, as it was just a matter of declaring the jetty dependencies in the maven pom.xml.

The tricky part was telling jetty where to find the war-file to serve. My first try was to hardcode the filename, but that left a foul aftertaste. Finding a solution took quite some time, which is why I am posting this for future reference. This is the Main-Class used to bootstrap Jetty (adapted from the Wicket quickstart archetype):

import org.mortbay.jetty.Connector;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.bio.SocketConnector;
import org.mortbay.jetty.webapp.WebAppContext;
 
public class Start {
 
  public static void main(String[] args) throws Exception {
    Server server = new Server();
    SocketConnector connector = new SocketConnector();
 
    // Set some timeout options to make debugging easier.
    connector.setMaxIdleTime(1000 * 60 * 60);
    connector.setSoLingerTime(-1);
    connector.setPort(8080);
    server.setConnectors(new Connector[] { connector });
 
    WebAppContext context = new WebAppContext();
    context.setServer(server);
    context.setContextPath("/");
 
    ProtectionDomain protectionDomain = Start.class.getProtectionDomain();
    URL location = protectionDomain.getCodeSource().getLocation();
    context.setWar(location.toExternalForm());
 
    server.addHandler(context);
    try {
      server.start();
      System.in.read();
      server.stop();
      server.join();
    } catch (Exception e) {
      e.printStackTrace();
      System.exit(100);
    }
  }
}

The interesting bit is the getProtectionDomain()/getCodeSource() part, which tells us the location of the war-file. That’s all there is to it. Presto, executable web-application powered by Jetty in jar.

Edit: Added the import statements as per Tim’s suggestion.

Tags: embedded, executable, hudson, jetty, servlet container, syndicate, war

I’ve been busy this weekend preparing one of the EclipseCon talks I will be doing together with Jordi. The background story to this talk is that we wanted to make it easier for users of Yoxos (and us of course) to deploy new versions of software along with relevant updates. Traditional “.war” deployments are very monolithic and inflexible. The deployment model is simplistic as you only have to support a single version (which may be advantageous to some). But for our needs, we needed a more modular approach to the problem. Since we are not in the business of reinventing circular transportation devices, we started looking at some existing technologies to get as much mileage as possible – so we can concentrate on other neat features.

With Equinox p2, Eclipse already has a powerful provisioning component that performs updates and installation of components… on the client side. Our goal was to leverage the effort that has gone into p2 and adapt the technology to work on the server side. The results are quite promising – with a small amount of effort, we could create a very flexible, modular and robust deployment mechanism. Has anyone else worked with p2 on the server side yet?

Find out more about the technical details at our talk “Down with WAR. Server-side deployment with p2” at EclipseCon. Hope to see you there!

Tags: eclipsecon, p2, server, war