Update: Since this post was published, RebelLabs has completed the full version of The Great Java Application Server Debate with Tomcat, JBoss, GlassFish, Jetty and Liberty Profile. Feel free to check it out!
In our previous Great Java Application Server Debate post, we covered IBM Liberty Profile, which isn’t exactly the slouch some of you may have been thinking. Our plan is to cover not only IBM Liberty Profile, but also Jetty, JBoss AS 7 and EAP, Glassfish, Tomcat and Tom EE, Oracle WebLogic, IBM WebSphere Application Server (proper). So get ready!
Next up on the great Application Server debate is Jetty. But before we start with that debate, let’s get this one out the way first – Jetty can host web applications and serve requests, so we consider it an application server. If you feel so strongly that you must object, feel free to knock your coffee over and kick the cat to get to your keyboard and type in your flame war opinion in the comments section below. For those who couldn’t care less about the name and care more about the tech, read on!
Read the complete Java Application Server Report where we discuss the pros and cons of App servers such as: Tomcat, Jetty, GlassFish, IBM WAS Liberty Profile and JBoss (aka WildFly):
Jetty is an extremely lightweight server with options to easily configure and extend it. It was initially developed in 1995 and over 18 years of development it has preserved its lightweight size and simplicity.
For the more hardcore app developers there is a project called Jetty Hightide that provides additional features such as JNDI, XA transactions, JMS and more, to bring it inline with some of the more traditional appservers.
Jetty’s USP statement is “Don’t run your apps inside Jetty, run Jetty inside your apps!”. This is true, as setting up Jetty as an embedded container takes just a couple of minutes with some copy-pasting from the wiki.
I have used Jetty in the past with couple of projects for many years. And so far, from my developer’s point of view, it has proven itself as a very handy and productive server for testing and running web apps.
Download and install
The documentation recommends using Jetty 9. I downloaded the latest Jetty 9 stable build. I discovered that it is only 8MB in size! What a blessing, it doesn’t come packed full of hundreds of megabytes of stuff that I don’t need, want or care about. The process is easy after that:
- Download installation package
- Extract the archive
- You are ready to go!
Throughout all versions, Jetty has preserved its simplicity in starting it up:
java -jar start.jar
This command starts Jetty up using default settings, which are fine for the majority who want to quickly get their webapp up and running without fuss.
It is also possible to install Jetty on Linux using APT or YUM, but keep in mind that versions from repositories will always be a couple of levels behind the latest stable build.
Run Forrest, run!
Deploying an application is relatively easy as well – just copy your .war under the webapps folder and you are done! Jetty finds the app and deploys it automatically.
Also you can provide your own context XML files like you may already be familiar with, using other app servers.
Jetty also provides a startup script called “jetty.sh” for *nix systems under the “bin” folder, but you can also live without it. That’s another beauty of Jetty – no magical startup scripts are actually needed. In this way, it is also easy to attach any javaagent to your application without messing around with environment variables or deep startup script changes.
But I want to do everything my own way!
No worries at all – you can make your own XML based configuration file and pass it along with the startup command:
java -jar start.jar /path/to/your-jetty-conf.xml.
One thing that I really love about Jetty is its simplicity in setting the HTTP port. If you want to use something else than 8080, then just put “jetty.port” inside the jetty.xml:
<Set name="port"><Property name="jetty.port" default="8080" /></Set>
Or those who are impatient, can just start up their instance with:
java -jar start.jar -Djetty.port=80
Also, it is possible to pass multiple configuration files to Jetty like configuration for HTTP and HTTPS, which is very useful for sharing snippets of config around a team.
java -jar start.jar /path/to/jetty.xml /path/to/jetty-ssl.xml
Jetty’s configuration is reflection-based. This means that all options in XML are actually corresponding to the Java class fields. You can just open the javadoc and start creating your own configuration with whatever options you need. You can screw something totally up or invent your own thread pool or a customized session handler etc.
As you can see below, the
Configure element uses
org.eclipse.jetty.server.Server as it’s class and will define a
threadpool as its constructor argument:
<Configure id="Server" class="org.eclipse.jetty.server.Server"> <Arg name="threadpool"> <New id="threadpool" class="org.eclipse.jetty.util.thread.QueuedThreadPool"> <Arg name="minThreads" type="int">10</Arg> <Arg name="maxThreads" type="int">200</Arg> <Arg name="idleTimeout" type="int">60000</Arg> <Set name="detailedDump">false</Set> </New> </Arg> </Configure>
Check out the javadoc for the Server class.
This way of extensive configuration actually provides you endless possibilities. Thats probably the reason why Jetty is used in Google App Engine and Heroku (they need probably their own session & transaction management).
The biggest downside with this reflection-based (not so well documented) approach is that you need to understand how Jetty works under the covers and learn some of its internals. But hey – if you know your server well, you’ll never run into anomalies and won’t let the server to go out of control, right?
Gimme the hammer and I’ll hit the nail!
I’d say that Jetty’s tooling is quite well developed. It’s well integrated with Ant, Maven or can be integrated with the tool you like.
Jetty has a very nice and convenient plugin for Maven (my own sample conf):
<plugin> <groupId>org.eclipse.jetty</groupId> <artifactId>jetty-maven-plugin</artifactId> <configuration> <scanIntervalSeconds>10</scanIntervalSeconds> <webXml>src/main/resources/web-dev.xml</webXml> <webApp> <contextPath>/myapp</contextPath> </webApp> </configuration> </plugin>
It is possible to configure your development environment very closely to the one that you are running in production. The maven plugin for Jetty allows you to configure almost everything in the pom.xml file.
And finally, just run the following command to start the server – sweet!
The thing that I love with Maven’s Jetty plugin is that Jetty is so tiny. So it won’t take long for Maven to download all the internets.
Jetty has an Eclipse WTP plugin that enables you to run web apps directly from Eclipse like you may have seen with other appservers. But currently the Eclipse Jetty WTP project is unmaintained :(
Can I run real apps as well?
As Jetty itself is largely just a container, it misses many components that would needed when running more serious apps. There is a Jetty distribution called “Hightide”, that provides components and features that are needed to host apps requiring JNDI, JMX, annotations or Java EE integration.
Jetty 9 does not yet offer a distribution for Hightide but for those who want to use Hightide, there is a distribution based on Jetty 8 available now.
Jetty Hightide includes JNDI, JMX, annotations and also JEE integrations. But even with all those awesome features it remains lightweight – Hightide is only 24 megabytes in size.
As with the regular Jetty installation, Hightide also provides numerous usage and how-to examples to help you understand and use its Java EE integration and features.
Administration & managing
Probably one big drawback is the lack of a management console that you may be used to using with a server like Tomcat (Tomcat Manager) or JBoss AS. With that being said, it may be hard to manage big production environments with Jetty, unless you use an awesome tool like LiveRebel, of course!
Jetty is very developer friendly, but less DevOps/operations friendly. As mentioned, third party products are available that plug into containers to build manageable development and production environments at the same time, but this does not come out the box with Jetty.
Developers are not getting lost with 500MB installation packages and DevOps can still understand and see key metrics such as what is going on, what is running where and how healthy the application is.
As mentioned earlier – Jetty is not equipped with advanced management console and tools and this makes it hard to scale and configure in bigger environments. Operations team may get very frustrated and create inconsistencies when dealing with changes to some XML or property files on multiple servers. Jetty does need still some better tooling, both on the management and development sides.
But after all – it is very handy server for developers and suitable for websites with higher performance and configuration demands.