Java servlets are essentially Java programs which extend the functionality of a server. They are not confined to web servers, but are most often referred to in this context. Virtually all references to servlets cite them as a replacement for CGI scripts, so it is easiest to think of them as Java programs that perform CGI functions.
The intriguing thing about servlets is their claimed performance. Traditional CGI scripts written in Perl, C, etc. all have a disadvantage in that a new process must be created for each call of the script. The overhead of process creation and management can be very taxing on a loaded server. Servlets solve this problem by creating a thread for each request, rather than an entire process. A single process for each servlet is created, then a request to the servlet causes a thread to be created to handle it.
Sounds great, but how does one use servlets on Linux? Well, you need a web server that supports both servlets and a Java virtual machine. There are several choices in the web server department. Sun's Java Web Server will probably run on Linux (since it is written in Java), but it is commercial. We'll be using Apache in this article because it is free and is widely used. This means we need a servlet extension for Apache. Livesoftware makes a product called JRun which I have heard great things about, but again, we'll stick strictly to the Apache side of the world and go with their mod_jserv extension.
Next, you'll need to choose a JDK (Java Development Kit) for your system. Again, there are several choices. Two worth mentioning are the Blackdown JDK (http://java.blackdown.org/) and the new OpenGroup JDK (http://www.camb.opengroup.org/RI/java/linux/), which uses a native threads implementation. Since threads are important to servlet performance, your JDK choice might significantly impact performance. I used the Blackdown JDK, because I was familiar with it and knew it was stable. However, the OpenGroup's work is worth looking into if you have the time.
To get servlets up and running on your system, follow the steps below. Note I assume the JDK you chose is installed and working.
The first step is to download the latest version of Apache (http://www.apache.org/) and the latest version of JServ (http://java.apache.org/). These were 1.3.1 and 0.9.11 respectively, at the time of writing.
The second step is to unpack each of the archives using the tar command:
tar -zxvf apache_1.3.1.tar.gz tar -zxvf jserv0.9.11.tar.gz
The third step is to compile Apache with the JServ module. Specify any options you need in the Apache configuration, but make sure to include an --add-module switch to specify where the mod_jserv.c file is located. Here is a simple example of an Apache configuration command:
./configure --prefix=/usr/local/apache --add-module=/usr/local/src/ jserv0.9.11/mod_jserv.cThis will automatically add the JServ module to your Apache configuration. Once configuration is finished, go ahead and make and install the package:
make make installThe fourth step is to compile JServ. Before compiling JServ, you must pick a location for installation. If you are happy with the directory where you unpacked it in step two, then you are set. Otherwise, just move the JServ directory to wherever you want it to reside. To keep things clean, you might want to put it in your Apache installation tree.
Next, the CLASSPATH variable needs to be set. Even though the JServ documentation suggests this may not be necessary, I found the package didn't compile unless it was explicitly set. The CLASSPATH variable must specify the path to your JDK classes and the JSDK classes included in the JServ package. My JDK lives in /usr/local/jdk1.1.6 and the JDK classes archive is in the /lib directory of this tree. I have JServ in /usr/local/apache/jserv, so my CLASSPATH variable would be set as follows:
export CLASSPATH=/usr/local/jdk1.1.6/lib/\ classes.zip:/usr/local/apache/jserv/servclasses.zip
Once this is set, change to the JServ directory and compile it:
cd /usr/local/apache/jserv makeStep five is to configure Apache. JServ requires that a number of configuration parameters be added to your Apache server configuration files. The files are typically located in the /etc directory of your Apache installation tree. Open up httpd.conf with your favorite editor and add the following configuration directives:
ServletBinary: the full pathname to your java binary. For example:
ServletClassPath: specifies the path to your various Java classes. JServ requires you to specify the path to the JDK, JSDK and JServ classes. For example:
ServletClassPath\ /usr/local/jdk1.1.6/lib/classes.zip #path to the JDK classes ServletClassPath\ /usr/local/apache/jserv/servclasses.zip #path to the JSDK classes ServletClassPath /usr/local/apache/jserv/classes #path to the JServ classesServletAlias: this is one of the most important directives, since it configures the location of your servlets and how they are accessed. The syntax of the directive is:
ServletAlias uri directory_or_filenamewhere the uri argument specifies how your servlets will be accessed via URLs, and the second argument points to the actual location of the servlets. The second argument can either specify a directory containing the servlets or a ZIP/JAR file containing a collection of servlets.
For example, if your ServletAlias directive was
ServletAlias /servlets /usr/local/apache/servlets
then URLs addressing your servlets would look like http://yourhostname/servlets, and the actual servlets would reside in the /usr/local/apache/servlets directory.
ServletProperties: gives the location of a file containing properties for your servlets. The path can be absolute or relative to Apache's server root and, if not specified, defaults to
Many properties can be set within the properties file. Arguments can be passed to all servlets with the statement:
servlets.default.initArgs=arg1=val1,arg2=val2,...Arguments can be passed to individual servlets as follows:
servlet.servletname.initArgs=arg1=val1,arg2=val2,...The sixth and final step is to fire up Apache. Well, you should be ready to go at this point, so go into the /sbin directory of your Apache tree and start up the server:
cd /usr/local/apache/sbin ./apachectl start
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide