Author: janb

If you’re looking for a fast and easy way to run your webapp, without needing to install and administer a Jetty distro, then look no further, the Jetty Runner is here! The idea of the Jetty Runner is extremely simple – run a webapp from the command line using a single jar and as much default configuration as possible:

  java -jar jetty-runner.jar my.war

Voila! Jetty will start on port 8080 and deploy the my.war webapp. Couldn’t get much simpler, could it?
You can also deploy multiple webapps – either packed or unpacked wars – from the command line. In this example, my.war will be available at http://host:8080/one and the my2 webapp will be available at http://host:8080/two:

  java -jar jetty-runner.jar --path /one my1.war --path /two my2

Or, for those webapps that need a little more configuration, you can run them via jetty context config files:

  java -jar jetty-runner.jar contexts/my.xml

You can configure the most common things from the command line, like the port to start on, and whether to generate a request log or not:

 java --jar jetty-runner.jar --port 9090 --log my/request/log/goes/here my.war

You can even configure a JDBC JNDI Resource entry right on the command line. Here’s an example to define a Postgres DB available in JNDI at java:comp/env/jdbc/mydatasource:

 java -jar jetty-runner.jar    --lib ~/src/tools/derby/ --lib ~/src/tools/atomikos     --jdbc org.apache.derby.jdbc.EmbeddedXADataSource "databaseName=testdb;createDatabase=create" "jdbc/mydatasource"    my.war

The syntax of the –jdbc argument is:

 --jdbc <classname of Driver or XADataSource> <db properties> <jndiname>

You’ll also have to tell jetty where to find your database driver and Atomikos, which we use to provide a transaction manager and wrap XA and non-XA Resources into a DataSource you can access from your webapp.
You’ll notice the –lib argument, which is one way to tell jetty about extra jars you want to put onto the container’s classpath. We also give you:

 --jar <filename> --classes <dir>

And as if all that wasn’t enough, you can get full configuration control using a jetty.xml configuration file:

 java -jar jetty-runner.jar --config my/jetty.xml my.war

You can see all your options with:

 java -jar jetty-runner.jar --help

How to get the jetty-runner.jar

The jetty runner is in the jetty-contrib svn repository and as such is no longer distributed as part of the standard jetty release.
At present, there is no distribution of the modules in the jetty-contrib repo (coming soon), however they are tagged
with the same release tags as the main jetty release.
So to obtain the jetty runner:

1. do an svn checkout from https://svn.codehaus.org/jetty-contrib/tags/jetty-contrib-<tag>, where tag is 7.0.0pre1 or higher release number, eg:
   https://svn.codehaus.org/jetty-contrib/tags/jetty-contrib-7.0.0pre1
2. mvn clean install
3. the jar file to use will be in target/jetty-runner-<tag>.jar

UPDATE 10 November 2008
 
The jetty-runner jar can be downloaded form the main maven repo at: http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-runner/
 
 

In one of those cosmic coincidences, no sooner do I blog about OSGi and J2EE containers, but Glassfish announces that they are moving to OSGi.

As OSGi gains more attention in the enterprise, the future is looking very interesting for Jetty, as we are hands-down the most popular servlet engine used in OSGi containers.

We already ported Jetty into Glassfish V2, back before Glassfish really offered any pluggability in the web tier, so we’re looking forward to a smoother ride with Glassfish V3 and OSGi modularity.

Oh, and just to be cheeky and because I like it, here’s the little gif I worked up last year when we demo’d Jetty inside Glassfish at the CommunityOne event, showing Glassfish "hooked" on Jetty:

🙂

OSGi is a set of specifications published by the OSGi Alliance  for modular Java-based services. OSGi has been around for a number of years, and was originally targeted at the network device market, but has increasingly been moving into the enterprise stream, where the ability to compose together diverse modules in a standard way is seen to offer significant competitive advantages.

As Jetty’s architecture has always been component-based and highly embeddable, moving Jetty into OSGi was something of a natural fit. A while ago, we were contacted by the Eclipse guys to tell us that they’d integrated Jetty into Eclipse’s OSGi container – called Equinox – as the Http service. We struck up a dialog and made some changes to Jetty to make it even easier to slurp into OSGi-land.  As an outcome of that dialog, we now publish OSGi manifests in all the Jetty jars so they become instantly visible when dropped into an OSGi container.

Lest you were thinking that Jetty is only in the Http layer in Equinox, we’re also embedded as the OSGi Http Service in most of the other well-known containers like Apache Felix and OPS4JPax. We’ve also been collaborating with the Spring guys on using Jetty in Spring Dynamic Modules, and are continuing to plow their feedback  into improving Jetty.

OSGi has now also been making inroads into the enterprise, an area which has traditionally seen a lot of  use of Jetty as the webtier in J2EE servers such as Geronimo, JBoss and EAServer. Enterprise servers are starting to adopt an internal OSGi architecture, which is again driving the uptake of Jetty. For example, JOnAS 5 now provides Jetty as a web-tier implementation, and Jetty is incorporated into BEA’s new OSGi-based microServiceArchitecture upon which their new enterprise offerings are based.  We’ve listed the OSGi containers that use Jetty here – we’d like to hear of any others you come across.

Interestingly, OSGi is also moving “down” the spectrum of Java environments from the enterprise level to the mobile level (from whence it came actually). For example, Sprint recently announced their OSGi-based Titan sofware environment for Win Mobile 6 PDA phones.  So given Jetty’s extensive OSGi integration and our proven embeddability, there will be a natural migration path for us to mobile OSGi platforms.  In fact, a mobile OSGi platform would prove an interesting challenge to Google’s Android platform, but as we’ve already got Jetty running on Android, we’ve got it covered either way!

 

Roberto Chinnici has posted a blog entry discussing the idea of introducing “profiles” in the JavaEE 6 specification(aka JSR-316).
Essentially, a profile is a subset of the enormous number of APIs/specs etc that a JavaEE platform supports. Over time, EE platforms have grown in complexity and size, leading to very large downloads and very large runtimes. Of course, if your app happens to use 99% of those APIs, you’re a happy camper (although IMHO your app could probably benefit from a long, hard think about it’s architecture 🙂 ). For very many – dare I even say the majority – of cases, the full EE environment just isn’t needed. In recognition of this, most of the well known application servers have released “lite” versions of themselves (although the success of the diet has to be measured in terms relative to the starting size and not the absolute outcome).
So that’s the motivation for the JSR’s consideration of  “profiles” – they’re a way of  slimming down the EE environment. A profile defines a minimum feature-set for a compliant product to implement, although a product could also choose to offer additional features, apparently with the provisio that a TCK must exist for those features.
The first profile they will be tackling is the Web Profile. Roberto lists 2 options under discussion:
Option A

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250

Option B

• Servlet 3.0
• JSP 2.2
• JSR-45
• EL 1.2
• JSTL 1.2
• JSR-250
• EJB 3.1 (Lite)
• JTA 1.1
• JPA 2.0
• JSF 2.0 *
• Web Beans 1.0

Whilst being the least heavy of the two, I actually think that Option A still has some dieting to do! The days are long past where one server-side presentation technology should be annointed as an essential part of a web container. These days many dynamic, slick web user interfaces are being created without the use of JSPs at all. Just have a trawl through the technologies listed on http://www.ajaxian.com to get some idea of the variety that is out there. By all means let Web Profile compliant containers provide JSP support as an optional extra. This would permit a migration path for existing web apps. However,  to mandate its inclusion at this point would be to look backwards in time rather than forwards into the future.
Option B, even minus all the JSP-related and derived technologies is still too heavy. I guess when you come right down to it, I think you can get a long way if your web container simply supports the ability to plug in extra services via JNDI. Want to use EJB3? Select one of the implementations available, throw it into the container’s classpath and hookup what’s necessary into JNDI and away you go. Want to use JPA? Throw an implementation library into the container’s classpath, hookup JNDI and again, you’re good to go. Not satisfied with your initial choice of JPA impl? Take it out and replace it with another.
In short, I’m not really sure that profiles are the answer. Is it really feasible to select a set of APIs and expect that one-size will fit all?  I think what we really need is the ability to run a web container and a mix of API implementations according to our needs, and I think to a large extent a web container + JNDI already provides this.
My experience with Jetty is that by using JettyPlus (which is essentially Jetty plus JNDI), you can plug in all manner of tools that let you get the job done. If you can’t be bothered to work out which implementations of the tools you want to use, then you can use something like Hightide, which is JettyPlus with a bunch of tools pre-plugged in. If you don’t like them, then you’re free to swap them for others.

I’ve modified the application is bundled into  Jetty  on adroid so that instead of a simple "Hello World" message,  you can now use the phone’s browser to look at content stored on the phone itself.

Here’s a few screen shots to give you the idea.

Starting Jetty:

The menu options to control jetty.

Jetty from the Home screen:

Notice the little jetty icon to the top left. You can click on that in any screen and drag it down to access the jetty menu.

Surfing to http://localhost:8080:

Clicking on the System option:

I’ve recently been working on porting Jetty to Google’s mobile platform called Android.
It’s early days still, but I’ve succeeded in running a minimal setup with a connector (I’ve tested both bio and nio connectors) and a simple Handler. If you’d like to take a look, then check out the code from the i-jetty project and build it (you’ll need to execute the ant build script and then use Android’s packaging tool or the Eclipse plugin).
Once you’ve built and deployed the i-jetty package to the emulator,  find the “Manage Jetty” application, and select the “Start Jetty” button. Then you’ll be able to select the Browser application and surf to http://127.0.0.1:8080 and hit the demo “Hello” Handler.
For the moment I’ve had to do a teeny hack to the servlet api classes, due to this bug in Android, but hopefully that will be fixed soon and I can revert the temporary patches.
Much work remains to be done, but I thought I’d give everyone early warning that this work was going on. Who knows, it might inspire someone to use Jetty to win the Android developer challenge?!

I just came across a very cool use of Jetty.
The folks at IBM alphaWorks have come up with an Eclipse plugin that translates your Eclipse UI into XUL and vice-versa so that you can effectively use your Eclipse from your (Mozilla-based) web browser! Jetty is the servlet engine providing the browser-to-Eclipse linkage.
Go and check it out at: www.alphaworks.ibm.com/tech/eclifox
One slight problem is that the first release of the plugin will only work on Windows platforms, however they’re working on an update that should be platform independent.
The plugin currently requires you to download the Jetty jars separately, however as Eclipse 3.3 and onwards ships with an internally available Jetty, the alphaWorks guys may well be able to hook into that in a future release, streamlining the installation process and reducing duplication.

Version 1.0.1 of the Jetty Plugin for Eclipse is available from:

www.webtide.com/eclipse/

This minor release fixes a problem whereby the automatic redeploy of a Dynamic Webapp project by the Eclipse environment did not trigger Jetty to redeploy.

Terracotta is an infrastructure that allows you to pretty much transparently cluster any code in a jvm. We’ve already successfully used it to cluster the channels in Jetty’s Bayeux (aka Cometd) implementation, so we thought it was high time we used it to cluster HTTP sessions.

Jetty already has a WADI-based solution for HTTP session clustering, so providing a terracotta-based solution provides an alternative for users to be able to choose the most appropriate solution for their needs.

The code is hot-off-the-press, so thus requires a little more polishing and testing, however it’s ready to try out, so give it a spin. Here’s the instructions:

Building

1. There are some changes to Jetty that have not yet been incorporated into trunk, so first you’ll need to check out this branch:

   https://svn.codehaus.org/jetty/jetty/branches/terracotta.
   

   Build it with:

   mvn clean install
   

   I’ll refer to the location where you’ve done the checkout as $JETTY-BRANCH.

2. Check out the session clustering code from the jetty-contrib repo at:

   https://svn.codehaus.org/jetty-contrib/jetty/trunk/extras/terracotta. 

   Build it with:

   mvn clean install
   I'll refer to the location where you've done the checkout as $TC_EXTRAS.
   



3. Copy the terracotta-sessions-6.1-SNAPSHOT.jar you just built into $JETTY-BRANCH/lib/ext.


4. Check out terracotta trunk from:

   http://svn.terracotta.org/svn/tc/dso/trunk
   

   Follow the instructions on the terracotta site to build it and produce a bootjar. I'll refer to the root of the build results (usually in code/base/build/) as $TC-BUILD.

Configuration

1. You can setup all your webapps to use terracotta-based session clustering by copying the example jetty config file in $TC-EXTRAS/src/main/resources/jetty.xml to your $JETTY-BRANCH/etc/ directory.
2. You might want to copy the example webapps from $TC-BUILD/dist/terracotta-trunk/samples/sessions into $JETTY-BRANCH/webapps to play with.

Running

Start the terracotta server:

$TC-BUILD/dist/terracotta-trunk/bin/start-tc-server.sh
-f $TC-EXTRAS/src/main/resources/tc-config-jetty.xml

Start jetty:

cd $JETTY-BRANCH
java -Dtc.install-root=$TC_BUILD/dist/terracotta-trunk/
-Xbootclasspath/p:[path to your boot jar]
-Dtc.config=$TC-EXTRAS/src/main/resources/tc-config-jetty.xml
-jar start.jar
etc/jetty.xml

Job done!

Any webapps you deployed should have their session instances clustered. Don't forget, you'll need to start more than one jetty instance in order to see session clustering actually happening 🙂

Many thanks are due to the guys at Terracotta for their expert help in the integration, in particular Tim Eck who was outstandingly helpful - thanks Tim!

Java One

If you're attending Java One, we'll be hanging out and demo-ing the session clustering at the Terracotta booth (booth #828) so drop by, eyeball the demo and come and have a chat to us.

Jetty has a sexy new plugin for Ant that has the same features as the Maven plugin. So if you didn’t want to move from Ant to Maven, but you still want fast webapp development, now you can have it!
The Jetty Maven plugin greatly shortens your development cycle by allowing you to run jetty on your Maven webapp project without first having to assemble it into a fully-formed webapp. Moreover, it’s able to scan the webapp and automatically redeploy it when changes are detected (eg to class files, descriptors, jars etc). You can imagine how convenient that is when you’re using an IDE – you modify the source, the IDE compiles it in the background and your changes are then immediately reflected in the executing container.
Not everyone, however, is in a position to change to using Maven for building their webapps. Many folks are happy with (or are stuck with) using Ant, but would love to have the advantages of the Maven plugin.
Well, now they can! The Jetty Ant plugin brings you those same rapid development features.
Like the Maven plugin, the Ant plugin also directly supports configuration of jetty components like connectors, realms, request logs etc. Similarly, it also supports the use of a jetty.xml file to give you total control of the container environment for your webapp. As you’d expect, you can also specify a jetty-env.xml for doing fine-grained configuration of the JNDI resources.
Once you’ve done your initial configuration and setup it’s as easy as typing:

ant jetty.run

Big thanks to Jakub Pawlowicz and Sabre Holdings for this outstanding contribution to the Jetty project!