Jetty: An Efficient, Easy to Manage Alternative to WebSphere
August 27, 2008 Mike Brown
|
Note: The code accompanying this article is available for download here. In the past couple of years, I have talked with colleagues and read articles about the complexity of WebSphere and the resources it uses. There are alternatives to WebSphere when you need a Servlet or JSP container. Apache Tomcat is probably one of the better known competitors to WebSphere. However, I would like to introduce you to another one that is smaller, easier to manage, and just plain works: Jetty. Introduction to Jetty Jetty is an open source Web server–implemented in Java–that provides Servlet and JSP support, among other things. Jetty has been around since 1995, has been incorporated in many products and tools such as the Eclipse IDE, and has a very active development community. You can get commercial support for Jetty from Webtide. In addition to Servlet and JSP applications, Jetty can work with numerous other technologies, such as EJB3, Java Server Faces (JSF), AJAX, Google Web Toolkit (GWT) and others. There is also support for clustering, SSL, JNDI, ActiveMQ, transaction managers, and Web services. The current version of Jetty, version 6.1.11 when this article was written, still runs on Java 1.4. This will be welcome news for those of us who may have older systems that do not support Java 1.5 yet. The upcoming version 7 will require Java 1.5. While I won’t go into it in this article, the Jetty Web server can be embedded inside a Java application. This means that you can deploy a Java application on the System i that provides a Web browser interface to manage and check the status of the running application. Let’s Get Started Download the current release of Jetty 6.1 from the Jetty download page to your desktop computer. The download zip for Jetty 6.1 is only 17 MB, which includes Java source code, optional modules, and the entire Web site of documentation for Jetty. When we deploy this to the System i, we can exclude some of these directories and files. As a comparison, the IBM download page for WebSphere application Server Express, version 6, indicated that the download size is 543 MB. Unzip the downloaded file to a directory of your choice. The contents of that install directory should look like Figure 1.
That is it for installation! For those of you who are curious with how this compares to the installation of WebSphere v6, check out this article that describes the steps for installing WebSphere on the System i. The installation of Jetty on the System i will involve copying a subset of these directories and files to the IFS. You will probably want to set up some jobs on the job scheduler to start and stop the Jetty server so that it will always be available when you want it to be. Create a Deployment Directory Since you do not need the source code and documentation for deployment, create a new directory that to use for deployment to the System i. This new directory will contain a subset of directories and files from the install directory. The new directory should contain the directories and files shown in Figure 2.
While this configuration still includes example applications and optional libraries, at under 15 MB, I wouldn’t worry about it too much! If you really wanted to reduce the amount of disk space required for the installation on the System i, you could remove some optional jar files in the lib directory. However, I do not recommend that. You may have a Web application that needs those features in the future. After playing around with the sample Web applications, you can safely delete all the files and directories in the webapps and contexts directories. This step will remove the sample Web applications. Running and Stopping Jetty Open a command shell/window on your computer and change your current working directory to the Jetty deployment directory you created above. To start the Jetty Web server, enter the command: java -jar start.jar. On some computers, you may also be able to run Jetty by double-clicking on the start.jar file. Jetty will write logging information to the standard output (the command window usually) by default. When Jetty has completed the initialization process, you will see the following message: INFO: Started SelectChannelConnector@0.0.0.0:8080. Jetty uses Apache log4j to handle logging for the application. You will want to eventually change the logging configuration to write to a file instead of standard output. The logging configuration file, log4j.properties, is found in the resources directory. The default configuration tells Jetty to use port 8080 for HTTP requests. So, let’s fire up a Web browser and see what we get. Enter the URL http://localhost:8080 into your favorite Web browser and you should see a page like that in Figure 3. Try out some of the links to test the installation, if you wish. None of them are terribly exciting, but they do demonstrate that Jetty is a functional Web server and a Servlet/JSP container.
To stop the Jetty Web server, type CONTROL-C in the command window. This obviously is not a good approach for production use and Jetty provides a better alternative. Using additional command line arguments when Jetty is started, you can instruct Jetty to listen for a specific stop command. Here is an example command to start Jetty so that it listens for a stop command on port 9090 and requires a password of i5Rules: java -DSTOP.PORT=9090 -DSTOP.KEY=i5Rules -jar start.jar The command to stop Jetty given the above would be: java -DSTOP.PORT=9090 -DSTOP.KEY=i5Rules -jar start.jar --stop The commands above could easily be added to the job scheduler to start and stop Jetty at specific times. I would suggest creating scripts, named start.sh and stop.sh, with the appropriate commands above in your deployment directory. If you plan to use these scripts in the job scheduler, you will need to add a line before the java command that changes the current working directory to the location you will install Jetty. This will allow the java command to find the necessary dependent jar files. Deploying Jetty to the System i Now that you are familiar with starting and stopping Jetty, you need to get it installed on the System i. If you want to delete the demonstration applications that came with Jetty, you will need to delete all the files and directories in both the CONTEXT and WEBAPPS directories in the deployment directory. Create a new directory in the IFS for Jetty. I recommend that it be installed in /QOpenSys/jetty6.1.11. Using your favorite method (iSeries Navigator, FTP, etc.), copy all the files and directories in the Jetty deployment directory to /QOpenSys/jetty6.1.11. Once you have copied the files to the System i, start the Web server with the start.sh script that you created or enter the command manually in Qshell. Unless you are using the new 32-bit Java 1.5 environment, you will likely see a bunch of “Attaching Java program…” lines scrolling on the screen. If you have used Java before on the System i, you know this only happens the first time you run a Java application. When you run the start command the next time, the Web server will start much faster. Now that Jetty is running on your System i, test it out with the URL above (substituting the name or IP address of your System i). Sample Application I have created a very small project with NetBeans IDE that is available here. The project includes a very simple JavaServer Pages file and a very simple Java Servlet. These should help you get started writing your own. In addition, there is a Web application archive (WAR) file that contains the compiled version of the JSP and servlet. You can use this WAR file to practice deploying a new application to Jetty and configuring the Web server. Deploying Your Application The standard way to deploy a Java Web application is to create a WAR file, which NetBeans IDE does automatically for you when it compiles your source code and runs the project. We need to copy the WAR file to the WEBAPPS directory contained in the location you installed Jetty. If you followed my suggestion above, this would be /QOpenSys/jetty6.1.11/webapps. By default, Jetty is configured to monitor a specific directory for additions or changes to enable you to deploy or redeploy a Web application while Jetty is running. To make use of this feature, you need to create a small XML file and place it in /QOpenSys/jetty6.1.11/contexts. For this tutorial, I created demo.xml with the following contents: <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> <!-- ================================================================== Configure and deploy the demo web application in $(jetty.home)/webapps/demo ===================================================================== --> <Configure class="org.mortbay.jetty.webapp.WebAppContext"> <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <!-- Required minimal context configuration : --> <!-- + contextPath --> <!-- + war OR resourceBase --> <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> <Set name="contextPath">/demo</Set> <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/servlet.war</Set> </ Configure> The contextPath value will define the Web application context. So you access the application using a URL like the following: http://server:8080/demo. Once you place demo.xml in the contexts directory, you can test it out. This is the first time that I’ve discussed configuration of Jetty. That is because the default configuration of Jetty serves well for simple installations. If you need to change the configuration or use some advanced features, you can do so by editing XML files in the ETC directory where Jetty is installed. The resources section has a link to Jetty’s WIKI for configuration. I recommend making a copy of the XML files before you edit them so you can easily revert back if you need to. You’re Up and Running! While I don’t have first-hand experience installing and configuring WebSphere, I’m going to guess that it is a little more involved than what is explained here. Making configuration changes involves using a text editor to change readable and well commented XML files. So start experimenting with running Java Web applications today without worrying about how you will manage the server or about the resources being consumed on your System i. Mike Brown is the founder of comIT, LLC, a consulting company that provides architecture, project management, and development services. Mike’s experience ranges from compiler development to Department of Defense contract work to commercial IT systems. Send your questions or comments for Mike to Ted Holt via the IT Jungle Contact page. RELATED STORY AND RESOURCE Installing WebSphere Application Server 6.0
|
