ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

What Is Jetty

by Q Ethan McCallum
Jetty is an open source servlet container, which means it serves Java-based web content such as servlets and JSPs. Jetty is written in Java and its API is available as a set of JARs. Developers can instantiate a Jetty container as an object, instantly adding network and web connectivity to a stand-alone Java app.

In This Article:

  1. What's the Point of an Embedded Servlet Container?
  2. Setting up an Embedded Container: The Jetty API
  3. Externalizing the Configuration: XML-driven Config File
  4. The Executable JAR
  5. Conclusion
  6. Resources

Ask someone to name an open source servlet container and they'll likely mention Apache Tomcat in reply. Tomcat isn't alone in this world, though: we also have Jetty. Having another option for a servlet container is a plus, but Jetty's real claim to fame is that it is designed be embedded in other Java code. That is, the development team exposes Jetty as a set of JAR files such that you can instantiate and manipulate a servlet container in your own code, as an object. This opens up new possibilities for servlets and web apps.

Jetty is hardly a new face in the container crowd; it has been around in some form since 1998. It's released under the royalty-free, non-viral Apache 2.0 license, permitting free and commercial apps alike to incorporate it into their infrastructure.

In this article, I'll offer some ideas on why you'd want an embedded servlet container, explain the basics of Jetty's API, and show how to use its XML configuration to trim your Jetty-specific code to a minimum.

The sample code was tested under Jetty 5.1.10 and Sun's JDK 1.5.0_03.

What's the Point of an Embedded Servlet Container?

Before you adopt Jetty, it's reasonable to ask yourself why you would want a servlet container embedded in your application in the first place. What caught my eye was the potential to expose servlet functionality from within another, preexisting app. That presents possibilities for several groups, including Java EE application server vendors, software testers, and vendors of custom software. Most Java developers fall into one of these categories.

First, consider the fringe case of creating your own Java EE application server. Per the spec, a full-blown app server must offer servlets, EJBs, and other functionality. Instead of creating a servlet container from scratch, you could leverage existing, tested components and incorporate Jetty. This is exactly what the teams behind Apache Geronimo, JBoss, and ObjectWeb JOnAS did to create their Java EE app servers.

Software testers can benefit from creating a container on demand, when having several predefined containers is not desirable or possible. For example, a colleague once wanted a means to drive the unit tests for his web services code. Given his scenario -- several developers plus some automated unit tests running in Cruise Control -- I demonstrated how he could use Jetty to instantiate servlet containers on the fly inside his unit test suites. No extra scripts, no leftover files, just code.

For those of you that sell Java EE apps as your products, why give your clients a WAR file, and add container-specific headaches to your support costs? Instead, give them proper applications with their own start, stop, and management functionality. Even hardware vendors can benefit: Jetty's small memory footprint -- 350Kb for a plain HTTP (non-servlet) service -- makes it an option for appliances. You could provide web-based control panels with the full power of Java web apps but without the weight of a separate container component.

Finally, I'd wager the most interesting uses of an embedded servlet container would be from people who aren't writing traditional, browser-based web applications at all. It's possible to leverage a Java EE-HTTP combination as the backbone of a client-server app. Consider an event-driven service such as the (fictitious) Message-Driven Bank that launches from a main() method and waits for incoming requests, similar to a Unix-style daemon. It's only matter of time before someone wants that functionality exposed in a user-based fashion such as a GUI desktop app.

Creating your own infrastructure components -- here the protocol and socket communications code -- is often an unwelcome distraction from the task at hand, not to mention something else to debug later. Instead, you could use an embedded Jetty container to expose that business logic via HTTP, with minimal changes to the existing app. Toss in a Swing, SWT, or XUI GUI that packages requests as HTTP POST operations, REST, or even SOAP to complete the circuit. These may be less performant than a custom, domain-specific protocol; but for the time being you can leverage the existing, road-tested protocols and spare yourself the extra effort.

Pages: 1, 2, 3, 4

Next Pagearrow