Server-Side Java with Jakarta-Tomcat

When I began to write server-side web
applications, there were two mainstream choices: if you wanted the
program to execute quickly, you chose C, and if you wanted to write
the program quickly, you used Perl. C, as we all know, is great
when the binary needs to be small, fast and efficient. But C's lack
of automatic memory management and decent string handling, along
with the extreme care that programmers need in order to use it,
made it a poor second choice when compared with Perl.

But in the last few years, a number of programming languages
have begun to challenge Perl for the server-side web programming
mantle. In particular, Python has gained significant ground, thanks
in no small part to the growth of the Zope web development
environment.

But perhaps the largest groundswell of server-side
programming is coming from the Java community. Java, as many of us
might remember, began life as a client-side programming language.
For the most part, applets are an unpleasant memory of what happens
when you try to mix two client-side paradigms—a lesson that the
increasingly common use of Flash seems to ignore.

The basic unit of server-side Java is the
servlet, a small program that is
executed in response to an HTTP request and that generates a legal
HTTP response. Since servlets are written in Java, they are written
as object classes, inherit from a servlet ancestor and can take
advantage of Java's threading and exception handling. Moreover,
servlets (like all Java programs) run inside of a Java virtual
machine (JVM), an abstraction layer that can run on any operating
platform. This means that the same servlets can run on nearly any
operating system, providing even greater portability than CGI
programs.

I have used servlets in a small number of projects so far,
but this number is rising rapidly. Java is now the “in” language.
This is partly because Sun has invested a large amount in its
marketing, partly because it offers some technological and
infrastructural advantages over its rivals and also because it
poses a serious platform challenge to Windows. In addition,
server-side Java is the cornerstone for an increasing number of
Java-based application servers.

This month, we will begin to explore Java as a server-side
programming language. As a beginning step, we will install the
Jakarta-Tomcat environment for running servlets, as well as the
associated Jasper environment for creating Java Server Pages
(JSPs). In coming months, we will look at how to connect our
servlets and JSPs to a relational database, as well as how to use
Enterprise JavaBeans and the Enhydra application server for an even
more powerful environment.

Installing Java

When I first started to work with Java on Linux a few years
ago, the situation seemed fairly grim: while Linux was the best
known, open-source operating system, and Sun was promoting Java as
a universal programming language, it was difficult to impossible to
get a good version of Java for Linux. Some volunteer porting
efforts, particularly the one done by the Blackdown porters, were
impressive, but installation was prone to problems and not nearly
as stable as developers might have liked.

As I write this article in January 2001, the situation has
changed dramatically: you can now download a Linux version of the
latest Java development kit (JDK) directly from Sun's web site.
Further, the Tomcat servlet/JSP system works just fine on Linux. As
Linux picks up more steam, it is becoming an increasingly
attractive platform on which to program in Java.

Because my main Linux box runs Red Hat 6.2, I downloaded the
JDK 1.3 RPM from Sun's web site,
http://java.sun.com/. In
order to download the JDK, I had to sign up as a member of the
“Java Developer Connection”; while I'm not thrilled by the notion
of having to register in order to download software, it does not
seem like a terrible price to pay. The RPM cannot be installed
directly; first, you must agree to Sun's Java licensing
agreement.

Once you have accepted the agreement, the RPM is unpacked and
made available for install. You can then log in as root and install
the JDK, which is placed in the /usr/java directory. By putting
/usr/java/jdk1.3/bin/ in your PATH environment variable, you can
execute the javac compiler and the
java runtime environment without having to specify an explicit
path.

Once you have installed the JDK, you should run at least one
simple test to ensure that it works. Listing 1 contains a simple
program that can be invoked without any parameters and prints
“hello, world” to STDOUT. If the program is passed through any
parameters, it prints those parameters separated by a pipe
character (|).

To run the program, we must invoke the Java runtime
environment (java), giving it the name of our class (without the
.class suffix):

java Test

If we don't pass any arguments, we get the following output:

Hello, world

We can, however, pass arguments to our program:

java Test a b "q r s" 123

In this case, we get the following output:

a|b|q r s|123

In addition to setting your PATH correctly, you should set the
environment variable JAVA_HOME to point to the location of the JDK.
If you use bash, you can simply
put the following line inside one of your startup files:

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.