This casestudy describes how
Jetty
has been used on our own sites, to show that we are “eating our own dogfood”.
While there is nothing revolutionary in this blog, it is sometimes good to see
examples of the ordinary and I believe it is a good example
of how the simplicity and flexibility of Jetty has allowed simple things to
be done simply.
The jetty host is donated to the Jetty project by
Mort Bay Consulting
and
InetU, and the machine is
now not of the highest spec: 500Mhz Celeron with 128MB running FreeBSD at 1061
BogoMIPS ( about half the speed of my aging notebook ). On this
machine we run over 13 web contexts for 6 domains in a single
Jetty server with a 1.4.1-b21 Sun JVM using the latest release of Jetty 5.
The Sites:
The websites run by the server are for diverse purposes and
are implemented using diverse technologies:
| /jetty/* | – | The Jetty site is implemented as a serlvet that wraps a look and feel around static content and is deployed as a unpacked web application. |
| /demo/* | – | The demo context is custom context build with a collection of Jetty handlers using the java API called from the Jetty configuration XML. |
| /servlets-examples/* | – | The jakarta servlet examples deployed and run as a packed WAR. |
| /jsp-examples/* | – | The jakarta JSP examples deployed precompiled as a packed WAR. |
| /javadoc/* | – | The jetty javadoc in a jar file deployed as a webapplication. Because there is no WEB-INF structure, the jar is served purely as static content. |
| /cgi-bin/* | – | A context configured to run the Jetty CGI servlet |
| www.mortbay.com/ | – | The Mort Bay site is a look and feel servlet wrapping static content deployed as a standard webapplication. |
| www.mortbay.com/images/holidays | – | A foto diary site, created by deploying a directory structure as a webapplication so that it’s static content is served. A HTAccess handler is used to secure access to some areas (nothing exciting I’m afraid). |
| www.mortbay.com/MB | – | This blog site, which uses the excellent Blojsom web application using velocity rendering and log4j |
| www.collettadicastelbianco.com/ | – | A site about the Italian borgo telematico in which I sometime live and work. Written in dynamic JSP2.0 with tag files and heavy use of Servlet 2.4 Filters as aspects. Responsible for me finally liking JSPs |
| www.jsig.com/ | – | Static content web application. |
| www.safari-afrika.com/ | – | Static content web application. |
| www.ncc.com.au/ | – | Static content web application. |
Configuration:
The server is configured from a single Jetty XML file using explicit
adding of all contexts rather than automatic discover. Doing this is good for security, but also allows extra configuration to
be added for each context, such as customized logging.
While all domains have unique IP addresses, the site is actually configured to treat them as virtual hosts. This allows simpler
configuration of a single set of listeners for all contexts. A default root context is also configured to redirect requests without
a host header to an appropriate context.
Two listeners (http 8080 & https 8443) are configured using a shared thread pool of max 30 threads. Ipchains is used to redirect
port 80 and 8443 to these listeners and the server is run as an unpriviledged user.
Two authentication realms are defined, for jetty demo and jakarta servlet demo. Both use simple property files.
The realm name is used to map the realm to the webapplications.
Logging:
Jetty 5 usings commons logging plus the Jetty 4 logger wrapped as a commons logger. This is configured in the jetty.xml
to log to a file that is rolled over daily and historic files are kept for 90 days. A specific logger instance is
declared for the classes from the colletta web site. This logger is also mapped to the context name so that
ServletContext.log calls are also directed to it by jetty and all the log information generated by the app is in one file.
NCSA requests logs are defined for all the main contexts and a catch all request log is defined for those without.
The webalizer utility is used to generate regular reports of our loads on each context.
Conclusion:
The whole thing is kept running using the
Bernstein daemontools supervise program which calls “java -jar start.jar”
with no special parameters.
So really nothing unusual to see here, just business as usual, so move on…