PDF JavaServer Pages 2nd Edition Larne Pekowsky download

Visit https://ebookgate.com to download the full version and
explore more ebooks
JavaServer Pages 2nd Edition Larne Pekowsky
_____ Click the link below to download _____
https://ebookgate.com/product/javaserver-pages-2nd-
edition-larne-pekowsky/
Explore and download more ebooks at ebookgate.com

Here are some recommended products that might interest you.
You can download now and explore!
Advanced JavaServer Pages 1st Edition David M. Geary
https://ebookgate.com/product/advanced-javaserver-pages-1st-edition-
david-m-geary/
ebookgate.com
Core JavaServer TM Faces 2nd Edition David Geary
https://ebookgate.com/product/core-javaserver-tm-faces-2nd-edition-
david-geary/
ebookgate.com
JavaServer Faces in Action Kito D. Mann
https://ebookgate.com/product/javaserver-faces-in-action-kito-d-mann/
ebookgate.com
Pet pages unleashed fetching ideas for animal inspired
scrapbook pages 1st ed Edition Hitchingham
https://ebookgate.com/product/pet-pages-unleashed-fetching-ideas-for-
animal-inspired-scrapbook-pages-1st-ed-edition-hitchingham/
ebookgate.com

Creating Web pages all in one desk reference for dummies
2nd ed Edition Emily A. Vander Veer
https://ebookgate.com/product/creating-web-pages-all-in-one-desk-
reference-for-dummies-2nd-ed-edition-emily-a-vander-veer/
ebookgate.com
Creating Web Pages For Dummies 9th Edition Bud E. Smith
https://ebookgate.com/product/creating-web-pages-for-dummies-9th-
edition-bud-e-smith/
ebookgate.com
Que s Official Internet Yellow Pages 2005 Edition Joe
Kraynak
https://ebookgate.com/product/que-s-official-internet-yellow-
pages-2005-edition-joe-kraynak/
ebookgate.com
A Library of Stone Pages And other records of the Wesleyan
Burial Ground Saint John NB 2nd Edition Graeme F.
Somerville
https://ebookgate.com/product/a-library-of-stone-pages-and-other-
records-of-the-wesleyan-burial-ground-saint-john-nb-2nd-edition-
graeme-f-somerville/
ebookgate.com
Dictionary of Advanced Japanese Grammar Properly Scanned
Pages 1st Edition Seiichi Makino
https://ebookgate.com/product/dictionary-of-advanced-japanese-grammar-
properly-scanned-pages-1st-edition-seiichi-makino/
ebookgate.com

1
JavaServer Pages™ , Second Edition
By Larne Pekowsky
Publisher : Addison Wesley
Pub Date : August 15, 2003
ISBN: 0-321-15079-1
Pages : 368
Slots : 1

2
Copyright
Preface
Acknowledgements
Chapter 1. Introduction
Section 1.1. A Brief History of the Web
Section 1.2. Basic Dynamic Page Generation
Section 1.3. Solving CGI Problems
Section 1.4. Welcome to Java News Today
Section 1.5. Trying the Examples
Chapter 2. Simple JSPs
Section 2.1. Removing Text from a JSP
Section 2.2. JSP Errors
Section 2.3. Including Text in a JSP
Section 2.4. The Phases of a JSP
Section 2.5. Creating Custom Error Pages
Section 2.6. Java News Today
Section 2.7. Summary and Conclusions
Section 2.8. Tags Learned in This Chapter
Chapter 3. Using Beans
Section 3.1. Splitting Big Tasks into Manageable Pieces
Section 3.2. Defining Beans
Section 3.3. JavaBean Tags
Section 3.4. Making Data Available Throughout an Application
Section 3.5. Special Actions When Beans Are Created

3
Section 3.6. Making Beans Last Forever
Section 3.7. Java News Today and Beans
Section 3.8. Future Directions
Chapter 4. The Standard Tag Library
Section 4.1. Tag Libraries
Section 4.2. Tags with Bodies
Section 4.3. Dynamic Attributes in Tags
Section 4.4. Displaying Expressions
Section 4.5. Formatting Output
Section 4.6. Compound Data in the Expression Language
Section 4.7. Browser Detection
Section 4.8. Combining Tags
Section 4.9. Selecting among Multiple Choices
Section 4.11. Tags Learned in this Chapter
Chapter 5. Java News Today: Part I
Section 5.1. The Beans
Section 5.2. The Header
Section 5.3. The Left-Hand Navigation
Section 5.4. The Login Page
Section 5.5. The Quiz Result Page
Section 5.6. The Section Page

4
Section 5.7. The Article Page
Section 5.8. The Remaining Pages
Chapter 6. Databases
Section 6.1. A Quick Introduction to Databases
Section 6.2. A Language for Databases
Section 6.3. Using SQL Directly from JSPs
Section 6.4. Inserting Data from JSPs
Section 6.5. SQL and Beans
Chapter 7. Java News Today: Part 2
Section 7.1. Designing the Tables
Section 7.2. Adding Articles
Section 7.3. User Pages
Section 7.4. Other User Preferences
Section 7.5. Advertising
Chapter 8. Working with XML
Section 8.1. A Brief Introduction to XML
Section 8.2. Using XML in JSPs
Section 8.3. Selecting Data from an XML Document

5
Section 8.4. Processing XML in JSPs
Section 8.5. Formatting XML
Section 8.6. Java News Today and XML
Chapter 9. A Small Cup of Java
Section 9.1. Expressions
Section 9.2. Types
Section 9.3. Storing Values
Section 9.4. Method Calls
Section 9.5. Conditionally Evaluating Code
Section 9.6. Evaluating the Same Code Multiple Times
Section 9.7. Grouping Code
Section 9.8. Handling Errors
Section 9.9. Modeling a Problem with Objects
Section 9.10. Objects in Java
Section 9.11. Building Objects from Classes
Section 9.12. Sometimes Nothing Is Something
Section 9.13. Building Classes from Other Classes
Section 9.14. Interfaces
Section 9.15. Creating Groups of Classes and Interfaces
Section 9.16. Using Java in JSPs
Section 9.17. Database Access from Java

6
Chapter 10. Writing Beans
Section 10.1. How Beans Are Implemented
Section 10.2. Automatic Type Conversion
Section 10.3. How Beans Work
Section 10.4. Bean Serialization
Section 10.5. Events
Section 10.6. Special Events
Section 10.7. Bean Errors
Chapter 11. Servlets
Section 11.1. The Servlet Life Cycle
Section 11.2. The Servlet Class Hierarchy
Section 11.3. Servlet Events
Section 11.4. Forwarding and Including Requests
Section 11.5. Using Scopes from Servlets
Section 11.6. Using Beans from Servlets
Section 11.7. The JSP Classes
Section 11.8. Intercepting Requests
Chapter 12. The Controller
Section 12.1. Some Common Controller Tasks
Section 12.2. Support for Controllers: Struts

7
Chapter 13. Creating New Tag Libraries
Section 13.1. The Tag Life Cycle
Section 13.2. Tags without Bodies
Section 13.3. Tags with Bodies
Section 13.4. Using the Expression Language
Section 13.5. JSPs as Custom Tags
Chapter 14. Advanced Topics
Section 14.1. Declaring Variables and Methods
Section 14.2. Extending Different Classes
Section 14.3. Returning Other Kinds of Data
Section 14.4. Threads
Section 14.5. Advanced Error Handling
Appendix A. Summary of Tags
Section A.1. Built-in Tags
Section A.2. Core Tags
Section A.3. Format, Parsing, and Internationalization Tags
Section A.4. SQL Tags
Section A.5. XML Tags
Appendix B. Configuring a Web Application
Section B.1. Layout of the Directories
Section B.2. The Web.xml File

8
Preface
This is a book about how to use an exciting and powerful technology, JavaServer Pages,
(JSP) to create dynamic, interactive Web sites. As the name implies, this technology is
based on the Java programming language and inherits many of the language's features
and benefits. Most notably, Java makes JSPs available on almost every kind of computer
and operating system and certainly all those in common use.
JavaServer Pages are now a mature and stable technology, already in use in thousands of
companies. But maturity has certainly not led to stagnation! Recently, a new version of
the JSP specification was released, bringing new capabilities and possibilities. In addition,
several companion technologies have been developed to augment the fundamental
specification. The new specification, as well as the most important of these associated
technologies, are all covered in this book. Throughout this book, effort has been made to
show the capabilities of all these tools and to discuss how they can best be used.
One of the most important features of JavaServer Pages is how easy they are to use.
Anyone who is reasonably comfortable with HTML (Hypertext Markup Language) can
learn to write JavaServer Pages by using a few simple tags that may do very sophisticated
things behind the scenes, along with small packages of code called JavaBeans. This
allows for a very productive working relationship between HTML experts who build
pages and Java programmers who build beans and new tags.
Both kinds of developer will find material of interest in this book. Chapter 1 gives a brief
history of the Web, setting JSPs in context and clarifying what they are, how they work,
and why they work that way. Chapter 2 introduces some of the simpler features of JSPs
and shows just how easy the transition from HTML to JSP is.
The next two chapters introduce the two vital technologies that give JSPs their enormous
power and flexibility: JavaBeans in Chapter 3 and custom tags in Chapter 4. These tags
are presented as page authors will use them: components that hide all the complexities of
Java behind simple interfaces that can be combined and used in limitless ways. Chapter 5
uses beans and tags to build a fully functional Web site.
One of the great benefits of JSPs is that they make it possible for pages to interact with
complex systems. A very common such system is a database. Chapter 6 introduces
database concepts and discusses easy ways in which a page author can access data.
Chapter 7 uses this information to expand the utility of the site built in Chapter 5.
XML (Extensible Markup Language) is an increasingly important technology, and JSPs
are already well equipped to work with XML. This topic is covered in Chapter 8.

9
The first eight chapters comprise a logical first half of the book, dealing with the myriad
things page authors can do with JSPs without knowing anything about Java. The
remainder of the book delves under the hood to explain how all this is accomplished and
how Java programmers can extend the capabilities of JSPs. For readers who are not yet
familiar with Java, Chapter 9 introduces the language.
Chapter 10 covers the process of creating new beans. Chapter 11 covers a technology,
called servlets, that underlies JSPs. This information is then used in Chapter 12 to talk
about controllers, Java code that helps pieces of a Web site work together simply and
cleanly. Chapter 13 discusses how to use Java to create new tags. Chapter 14 covers a
few remaining advanced topics.
Readers who are not interested in programming will get the most out of this book by
reading Chapters 1 through 9, which comprise a complete course on how to use JSPs,
beans, tags, and related technologies to build just about any Web site imaginable. At that
point, such readers may wish to learn a little Java from Chapter 9 and then proceed on
through the rest of the book in order to understand better how everything works.
On the other hand, readers who already know Java but who may not be familiar with
JSPs, the new features added as part of the latest specification, or related technologies
will want to move quickly through Chapter 2 to get a feel for JSP syntax and then go
through Chapters 3 and 4 to see how JSPs interface with Java via tags and beans.
Programmers may then wish to proceed to Chapter 10 to see how new beans are created,
and from there through the second half of the book in order to understand servlets and
tags.
Finally, as amazing as it may seem, there is absolutely no cost to developing and
deploying JSPs! There is no need to buy a special server or particular hardware or
operating system. All the tools needed, and many others, have been released for free by
the Apache group. The CD-ROM accompanying this book contains these tools, as well as
all the examples from the book. It is my sincere hope that this book, in conjunction with
these tools, will help you get the most out of this revolutionary new technology for
building exciting, compelling Web sites.

10
Acknowledgements
This book is very much a group effort, and I am deeply indebted to everyone who helped
make it possible.
It has been my great pleasure to work with some of the brightest and most dedicated
people in New York at CapitalThinking. Although there are too many to name, I want to
thank them all for helping to keep technology fun and exciting enough to write about.
Almost every real-world consideration regarding server-side Java that appears in this
book came out of projects my colleagues and I worked on.
Many thanks and high praise to everyone at the Apache project behind Tomcat, the
standard tag libraries, struts, and so much more. Their decision to make such high-quality
tools free and open source deserves a round of applause from every Java and JSP
developer.
All the code in this book was developed on a FreeBSD system. I owe a debt of gratitude
to everyone behind both the operating system and the Java ports.
I would also like to thank everyone who took the time to read over the manuscript and
make suggestions. The final result is profoundly better for their efforts.
This book would be nothing but a collection of unread bits on my hard drive if not for
everyone at Addison-Wesley, including Ann Sellers, Jacqui Doucette, Debby Van Dijk,
Michael Mullen, Mary O'Brien, and the many others whom I may not have been lucky
enough to work with directly.
Finally, I would like to thank the artists who created the music that kept me company
while I was writing. Many of their names appear in examples scattered throughout the
text.
. . . and I wrote this book for evil gray monkeys who haunt me. . .

11
Chapter 1. Introduction
Since JavaServer Pages were introduced in June 1999, they have taken the world by
storm! Dozens of products are devoted to JSPs, and hundreds of companies are using
JSPs to build their Web sites and corporate intranets. The friendly .jsp extension can be
seen all over the Web.
The most significant of the many good reasons for this is that it is amazingly easy to
develop sophisticated Web sites with JSPs. Anyone who can write HTML can quickly
create rich, dynamic, and responsive Web sites that enable users to get the most out of
their online time. Through a mechanism called JavaBeans, JSPs have made it possible for
large teams or individuals working on complex projects to divide the work in such a way
as to make each piece simple and manageable, without sacrificing any power. JSPs also
provide a great deal of flexibility when generating HTML, through the ability to create
HTML-like custom tags.
In addition to this fundamental ease of development, high-quality JSP tools are readily
available and easy to use. Developers do not need to buy expensive software or commit
to a particular operating system in order to use JSPs. The CD-ROM accompanying this
book contains everything a JSP author needs to get started, and the tools are powerful
enough to serve even a midsized Web site without problems. These free, open-source
tools are stable and secure and run on nearly every platform. Of course, high-quality
commercial JSP tools are available as well, suitable for serving even the most complex
and high-traffic Web sites.
Although JSPs have been useful and powerful since the beginning, this is an especially
exciting time to be a JSP developer. The recently released version 2.0 of the JSP
specification provides even more features that simplify the process of creating Web sites.
In addition, a standard tag library that provides many JSP tags that solve a wide range of
common problems has been released. Finally, in the time since they were released, a
number of best practices for using JSPs have emerged.
This book covers all the topics: the basic powerful features of the JSP specification, the
improvements introduced with version 2.0, as well as the new standard tag library and all
the things it does. In addition, this book discusses how best to use these tools, based on
real-world experiences.
However, before we get into all the fun, let's take a look back at how the Web has
evolved. This will highlight the kinds of problems that Web authors have faced since the

12
beginning. Once this is understood, it will be clear how JSPs solve these problems and
make page creation so easy.
1.1 A Brief History of the Web
A Web transaction involves two participants: the browser and the server. As originally
conceived, the browser was supposed to be a very simple, lightweight program that
would allow users to navigate through data. This data could consist of plain text, HTML,
images, and so on, and the browser would render all the data in a way that humans could
understand and interact with. Data could be interconnected, and the browser would render
references between documents as an image or text that could be clicked or otherwise
selected.
Over time, regrettably, rapid development, the race to add new features, and poor
adherence to standards have caused browsers to lose the simplicity for which they once
strived. This has resulted in a situation best summarized by Internet legend James "Kibo"
Parry's description of browsers as "fragile assemblies of bugs, held together with Hello
Kitty stickers."
The server is an equally complex program. The server is responsible for finding the data
requested by the browser, packaging the data for transmission, and sending it back to the
browser.
In the simplest kind of Web transaction, the browser asks for a single document from the
server, and the server retrieves this data and sends it back, at which point the browser
renders it in an appropriate way for the user. This whole process is shown in Figure 1.1.
Figure 1.1. The relationship between browser and server.

13
This basic activity has many variations. The data being requested by the browser may
come from a user typing a URL (universal resource locater) directly, may be in response
to the user's clicking a link, or may be automatic, such as an image contained within a
page. In each case, the server will receive a properly formatted request for the data, no
matter how the request is generated on the client.
How the server fulfills this request also has many variations. In the simplest model, the
response may come from a file. Often, there is a simple relationship between URLs and
such files. For example, the URL
http://somesite.net/lyrics/This_Ascension/forever_shaken.txt might come from a file
called C:WebfilesThis_Ascensionforever_shaken.txt on the computer called
somesite.net.
However, just as the server does not care how the request is generated, the client does not
care how the response is constructed. Storing data in a file is perfectly adequate for
information that never changes, such as the lyrics to a song, or that doesn't change very
often, such as a band's tour schedule. When a new date is added to such a schedule,
someone can simply edit the file by using a text editor, such as emacs, vi, or notepad, or a
full HTML editor, such as Dreamweaver.
However, the file-based model does not work for information that changes very rapidly
or that requires input from the user. Following are a few of the ways in which a site might
need to take input from a user.
• Many Web sites are dedicated to getting stock quotes, and these sites are used by
uncountable numbers of people. If Web servers could do no more than send files
around, every site would need to have a separate file for every single stock in
existence. The result would be a huge set of files, and it would be difficult, if not
impossible, to keep them all updated.
• Although many e-commerce companies have gone out of business, e-commerce
itself is thriving, and the electronic shopping cart is now commonplace. This
activity would also be completely impossible without the ability to run programs
on the server. A site could still put its catalog online as a collection of files, but it
takes a program to keep track of what items have been ordered, as well as to
connect with the shipping and inventory systems to send the merchandise to the
user.
• Now that the Web is so big, the only way to find a particular piece of information
is with a search engine. Some companies, notably Yahoo, build huge,
well-ordered catalogs of Web sites, which could in principle be regular HTML

14
files. For a user to enter arbitrary text in an entry box and obtain a list of files that
contain that word requires a program to look through the files and find ones that
match.
• Users love Web sites where they can vote for their favorite celebrity, manage a
virtual stock portfolio, or compete against other users in a match of wits and
knowledge.
What all these situations have in common is that the content is now dynamic; it needs to
change based on time, user input or preferences, or any of hundreds of other attributes.
1.2 Basic Dynamic Page Generation
Fortunately, a solution to the problem of dynamic content has been available since the
earliest days of the Web. Rather than reading the data from a file, the server can run a
program in order to generate the data. This process is illustrated in Figure 1.2.
Figure 1.2. How a server generates dynamic content.
As far as the browser is concerned, this situation is identical to that when the data comes
from a file. The browser doesn't care whether the server obtains its data by reading a file
or running a program, as long as what it gets back is valid HTML. However, the fact that
a program is being run behind the scenes enables the content to be dynamic.
As shown in Figure 1.2, the mechanism by which the server and the HTML-generating
program communicate is called CGI (common gateway interface). Over time, the
terminology has shifted somewhat, and the programs themselves are now usually referred
to as CGIs.

15
The earliest CGIs were written in a language called C. A sample CGI written in C is
shown in Listing 1.1. It generates a Web page that contains the current time and date.
Listing 1.1 A sample CGI in C
#include <stdio.h>
#include <time.h>
int main(int argc, char **argv) {
time_t now;
printf("<HTML>n");
printf("<BODY>n");
time(&now);
printf("The time is now: %s", ctime(&now));
printf("</BODY>n");
printf("</HTML>n");
exit(0);
}
This CGI illustrates two important drawbacks to the way the earliest CGIs worked. First,
this program is clearly not a good format for HTML developers. Such a CGI could be
created only by a programmer, and it looks nothing like the HTML that page developers
are used to. In fact, this isn't even a good format for programmers. Each little piece of
HTML requires its own piece of C code. This is acceptable, if ugly, for a simple CGI
such as this, but for a more realistic example involving lots of tables and colors and
JavaScript, this would quickly become overwhelming. It would also make it difficult to
fix problems in the HTML or to make changes in order to make the page more attractive
or useful.
Owing to the speed at which C programs run, C is still frequently used for CGI portions
that are not directly related to the generation of HTML. However, C was rapidly
overtaken as the CGI language of choice by another language, called Perl. Perl's main
advantage is that it is extremely good at manipulating text, which eliminates some of the

16
overhead involved with C. Listing 1.2 shows the Perl equivalent of the CGI from Listing
1.1.
Listing 1.2 A sample CGI in Perl
#!/usr/bin/perl
$now = localtime(time());
print <<"<EOT>"
<HTML>
<BODY>
The time is now: $now
</BODY>
</HTML>
<EOT>
This CGI is a little better; all the code is in one place, and all the HTML is in another.
They are still in the same file, though, and tightly coupled, so there is no easy way for
different people to work on different portions. In addition, it was possible to move all the
code to the top only because of the simplicity of this example. In a more complex
example, it would likely still be necessary to intermingle the logic with the HTML.
Today, it is possible to write CGIs in almost every language available, even Java. In the
end, however, the CGI model itself has a number of intrinsic problems, regardless of any
language-specific issues.
The first problem is speed. Just the mere task of having the Web server locate and invoke
the CGI program may take up to half a second or so. This may not seem like much, but as
any impatient Web surfer can attest, those seconds add up.
Worse, this start-up penalty must be paid for every request, as once it has finished
processing one request, a CGI program exits and disappears from the computer's memory.
The next time it needs the program, the Web server must be restarted. This is particularly
a problem for complex CGIs that need to access a database or other system resource.

17
These programs need not only to start up fresh each time but also to load up their
resources.
The transient nature of CGI programs also limits what they can do, at least without help.
The shopping cart is a classic example of this. Clearly, a shopping cart will need to
remember which items a user has selected, but it cannot do this alone if it is going to
evaporate after each item is added. In more technical terms, CGI programs are stateless,
meaning that they cannot keep track of any data between requests. Most CGIs get around
this problem by saving all necessary information to a database before they exit, but this
can be slow and requires that the connection to the database be opened each time the
program is started.
Perhaps the most serious problem with CGIs is the way they mesh presentation with logic.
As noted, the presentation of a page is expressed as HTML and is typically written by
designers and/or expert HTML authors. Program logic, such as what to do on a stock
page if the requested ticker symbol does not exist, lives in the program code and is
written by programmers. Despite exceptions to this division of labor, both HTML coding
and programming are generally such complex and specialized activities that it is rare to
find someone skilled at both.
The problem here is that at some point, the HTML must be incorporated into the program
because ultimately, the program must generate the output; in order to do this, the program
must have all the HTML that will go on the page. This is bad for both the programmers
and HTML authors. When the design changes or new pages are designed, the HTML
authors cannot change the HTML directly because it is buried in the program. They must
present the new designs to the programmers, who must then incorporate the changes into
their code without breaking any functionality. The HTML authors must then try out the
program to ensure that the HTML that comes out is identical to the HTML that went in,
and so on. Hours of company time can be lost this way, and animosity can all too
frequently develop between the programming and production groups.
1.3 Solving CGI Problems
The problems of speed, lack of data persistence, and development have all been
addressed in a number of ways.
1.3.1 Speeding up CGI

18
As noted earlier, one of the biggest problems with CGIs is that a whole new program
must be started up for every request. A number of approaches have been taken to
eliminate this overhead.
One such approach is called Fast CGI. In this model, the CGI remains running instead of
restarting each time. The Web server passes the CGI requests to the program over a
communication channel called a socket, reads the HTML back over the same channel,
and then passes the HTML on to the user. This gives the situation illustrated in Figure
1.3.
Figure 1.3. Fast CGI.
In addition to solving some of the speed problems, this approach also solves the problem
of keeping state. Because the CGI program never exits, it can hold onto information
between requests. All that is then needed is a way for the CGI to recognize which user is
accessing the page, so it will be able to associate the right data with the right user.
Typically, this is accomplished by sending the user a cookie, a small marker that the
server first sends to the browser and that the browser then includes in any future requests
to the same server. Fast CGIs also allow programs to keep connections to a database open,
eliminating the need to reopen one for each request. This speeds things up another notch.
Some problems remain with Fast CGIs, however. Most notably, each CGI program is
now a separate process, and each will use up a portion of memory and some of the central
processor. This can be alleviated by putting the CGIs on a different computer from the
one where the Web server lives, but then the sockets must talk across the network, which
will slow things down. This will still be faster than having to start a new program each
time, so the situation is not all that bad.
Fast CGIs also introduce a new problem. Updating a regular CGI or adding a new one is
a pretty simple matter, simply replacing the old version of the program with the new one.
Updating a Fast CGI is a bit more involved, as the old version needs to be shut down and

19
the new one started, and the Web server needs to close down the socket and open a new
one. Installing a brand new Fast CGI is even more difficult and will typically require
some change to the Web server's configuration describing where the Fast CGI process is
running and other information. Most Fast CGI implementations will make this process as
automated as possible, but it may still require special system privileges to make all the
changes happen.
Fast CGIs can be written in C, Perl, or numerous other languages. Typically, the
programs look like regular CGIs, with perhaps some additional code at the beginning.
This makes it very easy for programmers to learn how to write Fast CGIs, but it leaves all
the same problems regarding the intermingling of program code and HTML.
Since the development of Fast CGIs, a few modifications to address these problems have
been made. Most of the popular Web servers can address the problem of too many
separate processes by allowing new dynamic functionality to be added to the Web server
itself. The idea is that new capabilities can be added to the Web server; when it sees a
request that it formerly would have passed off to a CGI, the Web server instead invokes
the new routines. This greatly enhances the speed of requests, as everything now stays in
one process. This architecture is illustrated in Figure 1.4.
Figure 1.4. Web server extensions.

20
Apache, perhaps the most used and most extensible Web server, took this idea a step
further and incorporated the Perl interpreter. This extension, called mod_perl, allows any
Perl program, with some minor modifications, to run as part of the Web server.
However, extending the Web server this way is not for the faint of heart! It typically
requires a lot of knowledge about the inner details of how the Web server works, as well
as very careful programming. If an error causes a CGI to exit prematurely, no harm is
done, as the next request will simply start a new one. Even Fast CGIs can typically
recover after a crash. But if an extension to the Web server crashes, the whole server is
likely to go down.
Updating extensions to the Web server is even more difficult than updating a Fast CGI,
and only a few system administrators within any given company will typically have the
knowledge and permissions to do so. This makes such an extension useful only for
adding very fundamental kinds of functions, such as new registration or security features,
and not at all well suited to CGI-like applications.
Another approach to improving performance was taken by application servers.
Application servers combine the best features of Fast CGIs and server extensions. Like
Fast CGIs, an application server runs as a separate process and stays running between
requests. This eliminates the cost of starting a new program each time. Like server
extensions, application servers are extensible, allowing programmers to add new features
as needed. This architecture is illustrated in Figure 1.5.
Figure 1.5. An application server.
In a sense, application servers can be thought of as enhanced Fast CGIs, whereby each
extension acts as a separate Fast CGI, but they all sit in the same process. This has
numerous benefits. For example, it was mentioned that a Fast CGI can maintain an open

21
connection to a database. Clearly, though, each Fast CGI running individually will need
its own connection. An application server can maintain a central "pool" of open
connections and hand one off to each component as needed.
Most modern application servers also support some form of load balancing. This allows
multiple instances of an application server to run, possibly on different computers. If one
application server gets too busy or one of the computers crashes, all requests can go to
another server. The users should never even notice the problem.
1.3.2 Separating HTML from Code
In parallel with the developments on the speed front, progress was made in separating
HTML from program logic. The motivation behind many of these approaches can be
understood by first considering a very simple CGI and building the complexity up from
there.
Consider again Listing 1.1, which is just about the simplest possible CGI. It has almost
no logic, except for the two lines needed to get the date and time. Mostly, it prints out a
bunch of HTML. Therefore, all the HTML could be pulled out of the CGI and put into a
separate file. The CGI would open this file, read the contents, and send them back to the
server. The HTML author could then edit the file without needing to touch the program
code.
Once this mechanism has been built, it is easy to extend it slowly in order to include such
things as the date and time. This is a specific instance of a general problem, namely, that
frequently a CGI will have to incorporate some data, such as the date or a user's name,
into the page.
However, the HTML author need not care where this data comes from. As far as the
design of the page is concerned, the important thing is that the date shows up where it
belongs. The HTML author could indicate this by using a special tag, perhaps something
like <date/>. If the CGI is written in Perl, this tag could even be a Perl variable, such as
the $now variable used in Listing 1.2. Now when it reads the HTML and before sending it
to the user, the program can look over the whole file for any occurrences of <date/>, do
whatever it needs to in order to get the date, replace the tag with the value, and then send
the page along.
This idea can be extended by creating more tags to indicate other common data or
behaviors. Essentially, the new tags define a new language that both the programmers
and the HTML authors agree to speak, and the CGI acts as a translator, converting tags

22
into actions. This sort of system is often called templating, as the HTML page with the
special tags acts as a template, or blueprint, for all the pages built by the CGI.
Unfortunately, this scheme is not quite powerful enough to do all the things dynamic
pages need to do. Or rather, by the time it does become sufficiently powerful, the set of
tags will be as complicated as any programming language, and we will be back to where
we started. Consequently, most systems built around this idea have introduced a few
mechanisms that allow this basic scheme to be extended dynamically.
The first is to allow the set of tags to be extensible. An HTML author creating a page for
a music catalog, for example, might need a tag to represent the artist's name. In an
extensible system, the HTML author could communicate this need to someone in the
programming staff, and the two could agree on a new tag to use. The HTML author could
then start using this tag while the programmer goes and writes the code that will respond
to it.
The system can also be extended in other ways. In addition to creating new tags, the
programmers could create new functions, which may be thought of as small magic black
boxes, with a slot to drop things into and a ramp where things come out. An HTML
author could, metaphorically, drop the name of a musical artist into the slot, and the
names of all that artist's albums would come spilling out from the ramp. Then tags could
be used to specify where on the page these album names should go.
Best of all, a programmer can extend a templating system like this by providing new
objects. In programming terms, objects are much like physical objects in the real world.
They have properties that can be obtained or changed, numerous complex ways in which
they may relate to other objects, and so on. In the previous example, instead of providing
a function, the programmer could provide an "artist" object. One property of this object
would be a list of albums, and an HTML-like tag could request this list. Each album
would also be an object, and some of its properties would be the year it was recorded, the
list of track names, and so on. In other words, the artist object would encapsulate all the
relevant information in one neat bundle. Again, tags could be created to access the
information from this object and the other objects it contains.
This concept is illustrated in Figure 1.6. The box at the top left displays the list of albums
as rendered in a browser. Below this is a simplified view of the "artist" object. The box
on the upper right shows a hypothetical page that could generate the data for the browser.
First is a tag that sets up the "artist" object withthe name of the artist in question; then
another tag retrieves the set of albums from the object and sends them to the browser.
Although highly simplified, the basic concepts are very similar to the way JSPs work.

23
Figure 1.6. A tag that uses an object.
New tags, functions, and objects can greatly extend the way the templates get data but
still do not allow much control over how that information is presented. For example, it is
easy to create a tag that means "get all albums by this artist," but it is much more difficult
to express the concept "display all the albums where the first track was written by the
lead singer." All the necessary information might be present in the object, but combining
that information in arbitrary ways may be infeasible.

24
Consequently, most templating systems allow for some form of scripting. Scripting
allows elements of a full programming language u
sually the language in which the
translation CGI is written to be included in the page. All languages have a way to
compare two pieces of text and do different things, depending on whether they match.
The example in the previous paragraph would require writing some code that checked
whether the name of the lead signer matched the name of the author of the first track.
This is once again mixing programlike code with HTML, but because most of the hard
work is done in the objects or functions, all the HTML authors typically need to know is
some relatively simple control structures that do such things as compare two values or
loop through a set of values, performing some action on each.
So far in discussing templating, nothing has been said about performance. Not
surprisingly, the speed of such a system may be less than ideal. First, the CGI has to be
started, then it has to read the template, then it has to look for all the special tags and
process them, and so on. All other things being equal, a system like this is likely to be
orders of magnitude slower than a CGI written entirely in C.
There is still hope for templating by mixing it with the performance-improvement ideas
that were discussed previously. In particular, it is possible to turn the templating CGI into
an extension to the Web server, which will eliminate the need to start the CGI up each
time a template is needed. This also allows templates to save state information, use
shared resources efficiently, and so on. Many such templating systems are alive and well
today, from PHP, a well-known hypertext preprocessor that mixes scripting commands
with HTML; to WebSQL, a templating system that provides easy access to databases; to
osforms, a system built by Object Design to work with its object database.
1.3.3 Servlets and JavaServer Pages
Let's reconsider some of the problems with CGIs. As previously noted, it is
time-consuming to have to restart a CGI program for each request. Because the program
does not persist between connections, it is difficult to maintain state. Although it is
possible to overcome these problems with Fast CGIs or server extensions, these make
adding new functionality relatively difficult.
Sun's approach to solving these problems is to use servlets. Just as an applet is a small
application that extends the functionality of a Web browser, a servlet is a small piece of
code that extends the functionality of a server.

25
Technically, a servlet is an object, written in Java, that is equipped to receive a request
and to construct and send back a response. Because servlets are written in Java, they
inherit all the language's power and strengths. One of these strengths is speed, as a great
deal of effort has been put into making Java perform well as a server language. Equally
important, Java is also a cross-platform technology, so it is possible to develop a servlet
under Linux, deploy it on NT, and move to Solaris when the site grows, all without
needing to change or recompile anything.
Of special interest to Web developers, Java is an intrinsically dynamic and extensible
language. This neatly eliminates the problems inherent in extending a Web server. If it
supports Java, the server can be told to load a new servlet with a minimal change to a
configuration file and without needing to recompile anything.
The servlet architecture is designed to eliminate the need to reload anything every time a
request is made. Instead, the servlet is loaded once, the first time it is needed; after that, it
stays active, turning requests into responses as quickly as the Web server can send them.
This gives servlets all the speed of Fast CGIs, with none of the hassles. In short, servlets
can completely replace CGIs, with no downside.
Servlets also have one additional advantage. Because Java was designed from the ground
up as a secure language, servlets can be run in a "secure sandbox," which will prevent
them from accessing any potentially sensitive system resources. It is certainly possible to
write a CGI that has no security problems, and there are tools to assist in this endeavor.
Nonetheless, many security breaches on Web sites happen through insecure CGIs.
The next logical step would be to build a templating system on top of servlets. However,
the Art Technology Group (ATG) had an even better idea. Instead of writing a servlet
that reads a file, figures out what to do based on special tags, and then does it, why not
translate the special tags directly into Java and then compile and run the Java code? This
would mean that the first time a page was requested, it would take a little longer to do the
conversion, but the second and subsequent requests would be as fast as a servlet. This
revolutionary concept, called page compilation, was introduced in ATG's application
server, called Dynamo. Sun was so impressed by the concept that it licensed the
technology for inclusion in its own Java Web Server. The JHTML model is shown in
Figure 1.7.
Figure 1.7. The flow of information through a JHTML page.

26
No idea is perfect on the first try, and page compilation had problems. Most significantly,
there were problems with the set of special tags that ATG had defined, which were
somewhat cumbersome, somewhat limited, and completely unlike the tags that other
templating systems were using. Over time, Sun has refined these tags to create
JavaServer Pages.
JavaServer Pages, or JSPs, combine the best features of the many approaches to dynamic
page generation we have discussed. JSPs are implemented in Java, so they are cross
platform and inherit all Java's other strengths. Because they are built on top of servlets,
JSPs are fast and can be changed easily. They are extensible, and programmers can easily
create new objects and functionality using JavaBeans, which page authors can use
equally easily.
Sun considers JSPs so important that they are included as a formal part of the Java 2
Enterprise Edition, the standard version of Java for large companies doing complex,
performance-critical tasks. Every major vendor of application servers has announced
support for JSPs, including ATG, BEA's WebLogic, IBM's Web Sphere, and many more.
JSPs have truly become an industry standard.
Best of all, the power of JSPs is not limited to big enterprises or companies that can
afford an application server. At the 1999 Java One conference, Sun announced a
partnership with the makers of the Apache Web server to provide full support for JSPs

27
under Apache. The resulting project, called Jakarta, has been refined and improved many
times since then and now allows anyone with a computer to develop and deploy JSPs c
ompletely for free.
1.4 Welcome to Java News Today
Throughout this book, we will be following the evolution of a fictional Web site called
Java News Today. JNT is a start-up company of Java enthusiasts who want to create a
compelling, up-to-the-minute site covering all things Java. Because it wants to attract and
maintain an audience, JNT will make its site as dynamic as possible. In addition to
updating the content frequently, the site is to have games, polls, search functionality, and
other interactive features. JNT also considers it very important to allow users to
customize and adjust the site to fit their own needs. The folks at JNT hope that lots of
users will make JNT their home page and that no users will move into a home they
cannot decorate themselves.
Everyone at JNT will openly admit to being a fan of the Slashdot site, at
http://www.slashdot.org, and the Java Lobby, at http://www.javalobby.org. Readers
familiar with those sites may notice some similarities in the features that JNT is trying to
build. But then, imitation is the sincerest form of flattery.
1.5 Trying the Examples
All the examples in this book have been included on the companion CD-ROM, so readers
can see them in action and experiment with changes. The CD-ROM also includes Tomcat,
the high-performance JSP engine provided for free by the Apache project, at
http://jakarta.apache.org. The version included is 5.0, the first implementation of the JSP
2.0 and servlet 1.3 specifications.
The CD-ROM also includes a number of third-party libraries that provide useful utilities.
These libraries include HypersonicSQL, a file-based database written in Java; Jaxen, a set
of Java classes for working with XML; and the Canetoad utilities, which provide a
number of utilities for working with beans.

28
Instructions for installing and running the examples can be found in the index.html file on
the CD-ROM. Most users can simply double-click this file to get started.

29
Chapter 2. Simple JSPs
Chapter 1 presented the case for dynamic sites and surveyed a number of techniques for
building such sites, focusing on the strengths of JavaServer Pages technology. With these
preliminaries out of the way, everything is in place to start creating some pages! This
chapter begins by introducing some of the simpler features of JSPs.
It is a time-honored tradition for computer books to start with an example that allows the
system being studied to introduce itself. This book is no exception, so without further
delay, Listing 2.1 contains our first JSP.
Listing 2.1 A simple JSP
<html>

<body>
Hello, world!
</body>
</html>
This may look like a plain old chunk of HTML, not a very interesting one at that.
However, when saved in a file called index.jsp and given to a JSP engine such as Tomcat,
this chunk of HTML becomes much more than a static block. In fact, this is a program
very similar to the programs in Listings 1.2 and 1.3.
As a program, this file contains a series of instructions that the JSP engine will follow.
Written out in English, these instructions are equivalent to the following:[1]
[1]
This isn't quite true. For the sake of efficiency, most JSP engines send out contiguous chunks of HTML all at once.
However, it is often helpful to think of JSPs as being processed one line at a time.
1. Send the text <html> to the user.
2. Send the text  to the user.
3. Send the text <body> to the user.
4. Send the text Hello, world! to the user.
5. Send the text </body> to the user.
6. Send the text </html> to the user.

30
More technically, a program called the page compiler converts the original file into
another little Java program, a servlet as discussed in Section 1.3. This servlet is what gets
run. Servlets are an important technology, and they are covered in more detail in Chapter
11. For the time being, these details are unimportant, and it is perfectly reasonable to
think of the JSP file itself as the program.
At this point, three different things are all going by the name index.jsp. One is the
original file, sitting in a directory from where it can be edited like any other file. Second
is the servlet, which is managed by the JSP engine and is generally not meant to be seen
directly. Third is the URL and the corresponding page as seen in a browser. To avoid
confusion, the specific meaning will always be indicated when it is not clear from the
context.
In this particular case, all the extra work of creating and running a program has not
accomplished anything. However, the translation has not been pointless, as it has created
a program from HTML. This is why JSP authors generally do not need to do much
programming themselves. The JSP engine is quite sophisticated and can turn a few
simple tags into very complex code. The servlet that is generated and the environment in
which this code runs are also very sophisticated, which removes even more of the
programming burden.
This program illustrates two of the basic rules for the JSP programming language:
1. Plain text turns into a command to send that text to the user.
2. Regular HTML tags turn into a command that sends that tag to the user.
2.1 Removing Text from a JSP
All it takes is a small change to Listing 2.1 in order to start exploring some of the things
the JSP engine can do. Note that the HTML comment, "Our first JavaServer Page," has
turned into a program instruction that sends the comment to the user.
To people building and maintaining pages, these kinds of comments are often useful
because they can clarify what a block of otherwise indecipherable HTML is meant to be.
However, because it is a regular part of the document, this comment will show up in the
"view source" function of a user's browser.
This is typically not a problem, although it is possible for these comments to contain
implementation details that might be confidential. Or maybe a page author was having a

31
bad day and used some comment space to rant about his or her boss or relationship or the
state of the world. These comments can be quite embarrassing if anyone happens to see
them.
So, here is a dilemma. Comments are useful to authors but useless, or worse, for readers.
JSP has a solution to this. The preceding HTML comment could be replaced with a JSP
comment, like so:
<%-- Our first JavaServer Page --%>
When it sees this tag, the page compiler will recognize it as a comment and will not put it
into the servlet that it builds. Hence, this comment will never be sent to the user and will
not show up when the user does a view source. Again, this effect is subtle and, frankly,
not that exciting. However, it does begin to show that what goes into a JSP file can and
will be different from what comes out. Further, this adds a third rule to the JSP
programming language: Text enclosed between comment tags (<%-- and --%>) does not
turn into an instruction at all but is simply ignored.
2.2 JSP Errors
As smart as the JSP engine is, it is also very literal minded. Like any other program ever
written, the best it can manage is to do what we say, which is not always the same thing
as to do what we want. When a JSP page does not specify what to do in exactly the right
way, the JSP engine sometimes has no alternative but to give up, return an error page,
and ask for help.
One common error is leaving out a closing tag. This might happen if a page author tries
to close a JSP comment as if it were an HTML comment, as in <%-- our first JSP -->.
A user who tries to access this page will receive a rather unsettling page giving a great
deal of information about the cause and nature of the error. The exact format of this
message varies between JSP engines; Tomcat generates a page such as the one shown in
Figure 2.1.
Figure 2.1. The Tomcat error page.

32
The most significant part of this message is the first exception line, which contains the
following:
/error1.jsp(1.4) Unterminated <%-- tag
This line concisely specifies what the problem is, along with the name of the file in which
the error occurred. The numbers in parentheses are the line number and the number of
characters within the line where the problematic tag starts.
A variation of this problem is even more insidious. Consider the following JSP snippet:
<%-- This is a comment -->
Hello, world.
<%-- This is another comment --%>
When a browser requests this page, the content will be missing, but no error will be
generated. The reason is that this time, the comment tag is closed; it just happens to be
closed by the second comment tag! This means that the page compiler will consider
"Hello, world" as part of the comment and will discard it.
2.3 Including Text in a JSP

33
Removing text from a page is only slightly useful; it is much more exciting to consider
ways in which a JSP can add data to a page. This data may come from any number of
places, such as a database, some Java code, or data explicitly provided by the user.
Regardless of the source, it will be the JSP's job to inject this data into the page.
The first and simplest place a JSP can get data from is another JSP. Listing 2.2 shows a
slightly modified version of Listing 2.1.
Listing 2.2 A JSP that includes another JSP
<html>
<body>
Hello again, world!
<jsp:include page="content.jsp"/>
</body>
</html>
This turns into a program just as Listing 2.1 did, and once again, all the HTML tags turn
into instructions that send those tags to the browser. The jsp:include tag turns into an
instruction for the JSP engine to run the program called content.jsp, which is shown in
Listing 2.3.
Listing 2.3 The included content
This is some text from content.jsp.
Note that Listing 2.3 contains a complete and valid JSP. A browser could request
content.jsp directly, and the response would be the message with no HTML or other tags.
However, the intended use is that the browser will request the top-level page, which will
render its content, and then the jsp:include tag will call content.jsp. Control will then
return to the original page, which will send the final closing body and HTML tags. The
result, as far as the browser is concerned, will look exactly as if all the HTML was in the
original page all along.
Errors to Watch For
Includes can suffer from the same kinds of errors as comments. First, tags can
be broken, such as <jsp:include page="content.jsp">, which is missing the
closing slash. The JSP engine will catch this error and report it as

34
/index.jsp(3,0) Expected "param" tag with "name" and
"value" attributes without the "params" tag.
It is also possible to attempt to include a file that does not exist, which will
usually happen because of a typo, such as typing headers.jsp instead of
header.jsp. In this case, the JSP engine will report "Can't read file headers.jsp,"
which is easily fixed.
Two files do not make for a very interesting site, but the jsp:include tag becomes much
more useful when there are many more files. In one common scenario, many files may all
want to include some common text. For example, every page on a site might have at the
bottom a clever or amusing quote that the site administrators change once a week. If this
quote is kept in its own JSP, it is necessary to change only that one file in order to change
the whole site.
Conversely, one file may want to include several others. A customized news site might
have separate JSPs for top headlines, technology stories, weather, and sports. Many
different combinations of content pages could then be easily created by simply choosing
which of these pieces to include. In this sense, using JSPs is a lot like building with
LEGOS: Whole sites can be constructed by combining simple blocks in different ways.
Both of these techniques will be used extensively later in this chapter.
Closely related to the jsp:include tag is another, called jsp:forward. Whereas
jsp:include includes the contents of one page within another, jsp:forward simply
sends the user to another page. This requires that the page issuing the jsp:forward have
no text other than blank lines either before or after the tag. This may not seem useful yet
but later will allow pages to make decisions about what content should be displayed.
2.4 The Phases of a JSP
Each JSP goes through two distinct phases. The first phase, when the translator turns the
file into a servlet, is called translation time. This translation from JSP to servlet happens
whenever the JSP file is modified.
The second phase, when the resulting servlet is run to generate the page, is called request
time. This happens whenever a browser requests the page. Different things happen in
each phase, and the distinction is important.
The handling of JSP comment tags happens at translation time. The translator simply
omits any text within comment tags, so the servlet will not even need to deal with it.

35
Conversely, the jsp:include tag is handled at request time. For every request that
comes in for the index.jsp URL, the content.jsp servlet will be run when the
jsp:include tag is encountered. In principle, this could have been done at translation
time; the chunk of HTML from the content.jsp file could have been dropped right into the
index.jsp servlet. This would be much less powerful, however. By processing includes at
request time, the contents of the included file can change independently of the main file.
Another advantage to processing includes at request time is that doing so ensures that no
JSP is fundamentally special or different. Every JSP is a little program that can be run by
requesting the corresponding URL through a browser; there is no distinction between
"top-level" and "included" JSPs. As mentioned, this means that a browser can directly
request an included file, such as content.jsp, which is often useful when testing page
components.
This also guarantees that all JSP elements will work the same way in all pages. This
means that JSP comments will be stripped out of included files and that the jsp:include
tag will work inside included files! Files can include files that can include files, and so on,
potentially to infinity.
For the sake of completeness, it is worth mentioning the translation-time version of the
jsp:include tag, called the include directive. This tag looks like this:
<%@include file="contents.jsp" %>
This tag is called a directive because it directs the page compiler to take some action. In
this case, when it sees the directive, the page compiler will embed the contents of the
contents.jsp file directly into the servlet that it is building for index.jsp. Subsequently, if
the contents.jsp file is edited, index.jsp will not change. Browsers will continue to get the
old message until the page compiler is forced to rebuild the index.jsp servlet.
Note that the include directive specifies what is to be included with file=, whereas the
jsp:include tag specifies page=. This nicely encapsulates the differences between the
two: The directive includes a file as it is building the servlet at request time, and the tag
includes another page at request time.
In some obscure instances, the include directive and the jsp:include tag are not
equivalent. For the most part, though, the two are functionally identical, and as the
jsp:include tag is more convenient, it will be used in preference to the directive
throughout this book.
2.5 Creating Custom Error Pages

36
Many other directives are available for issuing instructions to the page translator. One of
the most useful is called, not surprisingly, page.
This directive takes a number of forms, many of which will be encountered throughout
this book as needed. One immediately useful option allows a JSP to specify where the
user should be directed in the event of an error. Tomcat's default error page, as already
shown in Figure 2.1, can be useful to developers but more than a little scary to end users.
Ideally, users will never see an error page, but a good site plans for all contingencies and
so should include an error page that fits visually with the rest of the site and that allows
the user to continue what he or she was doing, to whatever extent possible.
Using a custom error page involves two steps. The first is to create the page, which can
be another JSP. However, error pages need to be treated differently from regular pages,
and so the page translator must be notified that a JSP will be used as an error page by use
of the following page directive at the very top of the file:
<%@ page isErrorPage="true" %>
Once such an error page has been created and properly identified, it can be used in one of
two ways. The first is globally, by telling Tomcat which error page to use for each type of
error. This is done through a configuration file and is shown in Appendix B.
In addition to the global approach, each JSP can specify its own error page through
another variation of the page directive, as in
<%@ page errorPage="error_page_url" %>
Here, error_page_url is the URL of the error page, relative to the current page. Both of
these versions of the page directive will be demonstrated in the next section.
2.6 Java News Today
Java News Today, our fictional news site, is ready to begin constructing its site. JNT has
decided to start with the new home page and for the moment will not worry about the
dynamic elements. The first version is shown in Listing 2.4.
Listing 2.4 The JNT index page
<%@ page errorPage="error.jsp" %>
<html>
<head>

37
<link rel="StyleSheet"
href="style.jsp"
TYPE="text/css"
media="screen">
<title>Java News Today: Welcome!</title>
</head>
<body>
<table width="100%"
border="0"
cellspacing="0"
cellpadding="0">
<tr>
<td width="15%" class="borders">
<%-- Big Empty Corner --%>
</td>
<td width="20" class="borders">
<%-- Little buffer for the curvy bit --%>
<img src="1x1.gif">
</td>
<td class="borders">
<%-- start header --%>
<center><h2>Java News Today: Welcome!</h2></center>
<%-- end header --%>
</td>
</tr>
<tr>
<td width="15%" class="borders"></td>
<td width="20" height="20">
<%-- The curvy bit --%>
<img src="corner20x20.gif">

38
</td>
<td><img src="1x1.gif"></td>
</tr>
<tr>
<td width="15%" class="borders" valign="top">
<%-- start navigation --%>
Navigation - none yet
<%-- end navigation --%>
</td>
<td width="20"><img src="1x1.gif"></td>
<td valign="top" align="left">
<%-- All content goes here! --%>
</td>
</tr>
</table>
</body>
</html>
JNT saves the contents of Listing 2.4 into a file called index.jsp, points its browsers at the
corresponding URL, and as expected sees the page in Figure 2.2.
Figure 2.2. The JNT home page.

39
Conceptually, this page consists of four major elements: the header, the navigation, the
content, and the HTML that connects it all together. Note the use of JSP comments to
delineate these sections. It is generally wise to mark off major functional areas of a page,
but as the end user is probably not interested in these fences, they might as well be JSP
comments instead of HTML comments.
Different pages will have different content, but it is reasonable to expect that the header
and navigation will be repeated all over the site, although doing so can be a major
headache. The author of each new page will have to remember to put these pieces in and
will have to worry about getting everything right. Worst of all, sooner or later will come
the hateful day when a new section is introduced and everyone has to go back and reedit
all their pages.
The solution for this nightmare scenario is, of course, the jsp:include tag. The header
and footer will be split into separate files. The header.jsp file will contain everything in
Listing 2.4 from <%-- start header --%> to <%-- end header --%>. Likewise,
navigation.jsp will hold everything from <%-- start navigation --%> to <%-- end
navigation --%>.
This technique of pulling out common chunks of HTML and putting them in separate
files is called templating, although the use of the word here is slightly different from that
in Chapter 1. Here, a template is merely an HTML page with some "holes" where text
should be, along with a way to indicate where this text should be found. The advantage is
that many pages can have the same spaces, and all these holes can be filled from the same

40
place. This makes it possible to keep the header in exactly one file and let each page have
a space that should be filled by this file.
So far, this might seem like a rather goofy thing to do, as the header and navigation are
currently so small. However, rest assured that they will grow in subsequent chapters, and
the advantages of removing them from the main page will become increasingly obvious.
One such advantage is that it now becomes easy to create alternative versions of the
home page. Because all the HTML elements remain in the main file, a simplified version
suitable for text-only browsers, such as Lynx, could be created with a page like that
shown in Listing 2.5.
Listing 2.5 A version of the home page without tables
<html>
<head>
</head>
<body>
<jsp:include page="header.jsp"/>
<hr>
<jsp:include page="navigation.jsp"/>
<hr>
<%-- The contents of each page go here --%>
</body>
</html>
Note that there are a lot of HTML elements. It would be a real pain to have to rewrite
them for every page on the site. Fortunately, the jsp:include tag can once again come
to the rescue. The idea is that everything above the content can be placed in one file and
everything below in another, and then each new page can be created as simply as writing

41
the content and including two files. This final version of the JNT home page is shown in
Listing 2.6.
Listing 2.6 The final version of the index page
<jsp:include page="top.jsp"/>
Content goes here!
<jsp:include page="bottom.jsp"/>
Now that's what a JSP should look like! For the sake of completeness, top.jsp is shown in
Listing 2.7 and bottom.jsp in Listing 2.8.
Listing 2.7 The top part of the page
<html>
<head>
<link rel="StyleSheet"
href="style.jsp"
TYPE="text/css"
media="screen">
</head>
<body>
<table width="100%"
border="0"
cellspacing="0"
cellpadding="0">
<tr>
<td width="15%" class="borders">

42
<%-- Big Empty Corner --%>
</td>
<td width="20" class="borders">
<%-- Little buffer for the curvy bit --%>
<img src="1x1.gif">
</td>
<td class="borders">
<%-- start header --%>
<jsp:include page="header.jsp"/>
<%-- end header --%>
</td>
</tr>
<tr>
<td width="15%" class="borders"></td>
<td width="20" height="20">
<%-- The curvy bit --%>
<img src="corner20x20.gif">
</td>
<td><img src="1x1.gif"></td>
</tr>
<tr>
<td width="15%" class="borders" valign="top">
<%-- start navigation --%>
<jsp:include page="navigation.jsp"/>
<%-- end navigation --%>
</td>
<td width="20"><img src="1x1.gif"></td>
<td valign="top" align="left">
Listing 2.8 The bottom of the page

43
</td>
</tr>
</table>
</body>
</html>
Top.jsp includes header.jsp and navigation.jsp, but it is perfectly OK for an included JSP
to include yet other ones.
One problem with the way this page has been split up is that the title tag is currently
hard-coded in top.jsp, and the page banner is likewise hard-coded in header.jsp. This is
quite easy to fix but requires a tag that has not been introduced yet and so will have to
wait until Chapter 4.
It is also worth pointing out that this page uses a style sheet to set various visual attributes
of the page. This in itself is not unusual; most Web sites do the same thing. However,
note that the style sheet being used is not a regular .css file but another JSP! This will
turn out to be very important when tackling customization, as it will allow the style sheet
itself to be generated dynamically! For the moment, this file is static and pretty small but
is shown in Listing 2.9 for those interested.
Listing 2.9 The style sheet
TABLE.form { border-style: groove;
border-color: #004400; }
TD.label { border-style: solid;
border-width: 1px;
border-color: #00aa00;
background: #00AA00;
color: #000000;
padding-right: 5px }
TD.form { border-style: solid;
border-width: 1px;
border-color: #004400;}
TD.borders { background: #66ffff; }

44
DIV.bordered { border-style: groove;
border-color: #004400; }
All versions of the index page now use the page directive to link to a custom error page,
and this error page is shown in Listing 2.10.
Listing 2.10 The error page
<%@ page isErrorPage="true" %>
<html>
<head>
<title>Java News Today: Error</title>
</head>
<body>
We're sorry, but an error occurred while building
your page. We will try to fix this problem shortly;
in the meantime please return to the
<a href="index.jsp">JNT home page</a>
</body>
</html>
Apart from the page directive at the top, this looks just like any other JSP. This is only a
very bare-bones example; a more realistic error page would include the same header and
navigation elements that the index page used, so as to make it look more like a regular
page on the site. In addition, a sophisticated error page could do something like notify the
site administrator that an error had occurred. Unfortunately, doing something like this
requires many features that have not yet been discussed, and so it will have to wait until
Chapter 14.
2.7 Summary and Conclusions

45
This chapter started down the exciting road of writing JSPs. The two phases of a JSP's
existence were discussed: the translation phase, in which JSP code is turned into a Java
servlet, and the request phase, in which the servlet is run to produce HTML.
So far, we have not even begun to scratch the surface of what JSPs can do. The next
chapter starts looking at some of the things that can be done at request time, which is
when the doorway to dynamic content really opens.
2.8 Tags Learned in This Chapter
<%-- --%> JSP comment
Parameters: None
Body: None
Anything within the comment tag is removed by the page compiler at translation
time.
jsp:include Include tag
Parameters:
page: Specifies the page to be included
Body: None
The named page is evaluated and the results included into the output at request time.
jsp:forward Forward tag
Parameters:
page: Specifies the page to be included
Body: None
Control passes to the named page. The calling page must not contain any text before
or after the tag.
@include Include directive
Parameters:
file: Specifies the file to be included
Body: None
The named file is included into the servlet built by the page compiler at translation
time.

Random documents with unrelated
content Scribd suggests to you:

There was a silence of a full minute, during which the young man’s
heart thumped loudly against his ribs. Was he listening to the voice
of one risen from the grave?
Then the weird singing recommenced, with a wail of passionate
despair in the notes—
“The world can never give
The bliss for which we sigh;
’Tis not the whole of life to live,
Nor all of death to die.”
He waited for a considerable time in a fever of thrilling expectancy
—but there was no more. Having made certain of this, his next move
was to acquaint himself with the personality of the performer. He ran
over to the ruins of the church, climbed in across a pile of broken
masonry—the small square enclosure was easily measured at one
glance—it was empty.
Then he walked slowly round, and examined the walls by the
dying light. No, his quest was vain, there was not a soul—
undoubtedly it had been a soul—to be seen. In the gathering
darkness, the now silent valley had grown very sombre, the trees
made awful shadows, and the forest seemed to stretch away up the
mountains, until it was lost in the dusky sky.
“In what direction did you ride to-day, Mark?” inquired his father as
they sat over their dessert.
“I cannot tell you precisely, sir; but I came home by the
cantonment.”
“A lovely spot; the authorities could not have chosen better, if they
had searched five hundred miles—good air, good water, good
aspect; and yet the last regiment died there like flies. The natives

say it is an accursed place, and not a man of them will go near it
after sundown.”
“I suppose you don’t believe in that sort of thing, sir; you are not
superstitious?”
“Not I,” indignantly. “Mércèdes was superstitious enough for fifty;
she had all the native superstitions at her finger-ends, and the
European ones to boot! There was very little scope left between the
two! Almost everything you said, or did, or saw, or wore, was bound
to have a meaning, or to be an omen, or to bring bad luck. I
remember she was reluctant to start from Mussouri the day she met
her death, simply because she found a porcupine’s quill upon the
doorstep! I have seen some queer things in my day,” continued
Major Jervis. “When we were quartered at Ameroo I got a fright that I
did not recover from for months. I had lost my way out pig-sticking,
and was coming back alone, pretty late. At one part of the road I had
to pass a large irregular strip of water, and there standing upright in
the middle of it was actually a skeleton, swaying slowly to and fro; I
shall never forget that blood-curdling sight—and I don’t know how I
got home, to this very day.”
“And how was it accounted for?”
“By perfectly natural causes, of course! Cholera had broken out at
a village close to where I saw the spectre, and the people had died
in such numbers that there was no time for the usual funeral pyre. It
was as much as those spared could do to bring the corpse to the
spot, tie a gurrah (those large water vessels) to head and feet, fill
them with water, push the body out, and then turn and fly almost
before it could sink out of sight! My ghost was one of these bodies.
The gurrah from the head had broken away, and that at the feet had
pulled the corpse into an upright position, and there it was, a
spectacle to turn a man’s brain! We were quartered at Ameroo for
four years, and I never passed that miserable spot without a
shudder. When I last saw it the water lay low, covered with the usual
reddish-looking Indian water-weed; down by the edge was a skull
blackening in the sun. That hideous pool was the grave of two
hundred people.”

“And so your ghost was accounted for and explained away,” said
Mark. “Did you ever come across anything, in all your years out here,
that could not be accounted for or explained away?”
“Yes, I did; a queer, senseless, insignificant little fact, as stubborn
as the rest of its tribe. One morning many years ago I was out
pigeon-shooting with some fellows, and we came upon a large
peepul tree, among the branches of which waved sundry dirty little
red-and-white flags, and under its shade was a chabootra, about
fifteen feet square, and raised three feet off the ground. Mounting
this, in spite of the protest of a fakir, we discovered a round hole in
the centre, and looking down, we perceived filthy water, covered with
most unwholesome-looking scum. The sides of the well were hollow
and uneven and had a sort of petrified appearance. We asked the
reason of the signs of “poojah” we beheld, and heard the simple
story of the water in the well. It never increased or decreased, no
matter if the weather were hot and dry, or cold and wet; no matter
whether rain fell in torrents, or the land was parched with drought,
whether sugar-cane juice or the blood of the sacrificial goat was
poured in by buckets full, or not at all. It might be closely watched, to
show that it was not regulated by human hands, and it would be
seen that it never changed. Therefore it was holy. The god “Devi”
was supposed to be responsible for the curious phenomenon of the
water always standing at the same level—about four feet from the
mouth of the well, and never increasing its depth—said to be thirty
feet. Over and over again I revisited the spot, so did others—and we
never discovered any change. That was a fact we could not explain.
All the same, I do not believe in the supernatural!”
As his father did not believe in the supernatural and was likely to
be a sceptical listener, Mark resolved to keep his experience to
himself; perhaps there might be a natural cause for it too.
The arrival of a visitor to the Yellow House was not lost upon the
neighbourhood; several young planters flocked down to look him up,
and discussed fruit crops, tea crops, and the best beats for gurool,
the best rivers and lakes for mahseer, and gave him hearty
invitations to their respective bungalows. The German missionary
sought him out, also Mr. Burgess the American doctor and padré,

who worked among the lepers. He, like his predecessors, had been
struck with the remarkable and almost magical change that had been
wrought in and around the Pela Kothi. He beheld his patient, Major
Jervis, in a comfortable airy room, dressed in a neat new suit,
reading a recent Pioneer like a sane man. Like a sane man, he
discussed politics, local topics, and with greater enthusiasm his son,
who unfortunately was not at home. Presently an excellent tiffin was
served to the visitor, he was conducted round the garden, and as he
noted the improvements in every department, he came to the
conclusion that Jervis, junior, must be a remarkable individual. He
had an opportunity of judging of him personally before he left, for he
rode up just as Mr. Burgess was taking his departure, regretted that
he had not arrived sooner, and calling for another pony, volunteered
to accompany the reverend guest part of the way home.
A spare resolute-looking young fellow and a capital rider, noted Mr.
Burgess, as Mark’s young pony performed a series of antics all the
way down the path in front of his own sober and elderly animal.
“Your father is wonderfully better. I am his medical adviser, you
know,” said the missionary.
“Yes, and I wish you lived nearer than twelve miles.”
“He has a wonderful constitution. He has had one stroke of
paralysis, he may be taken suddenly, and he may live for the next
thirty years. Is it long since you met?”
“I have not seen him till lately—since I was a child.”
“That is strange, though of course India does break up families.”
“I was adopted by an uncle, and lived in London most of my time.”
“Ah, I understand; and came out to visit your father.”
“Yes, partly; indeed, I may say chiefly.”
“And have thrown in your lot with him. Mr. Jervis, I honour you for
it.” Mark looked uncomfortable, and his companion added, “This life
must be a great change, indeed, as it were another form of
existence, to you; you must not let yourself stagnate now you have
set your house in order, but come among us when you can. There

are Bray and Van Zee, the two nearest planters to you, both good
fellows. You have a much nearer neighbour, that you will never see.”
“Indeed, I am sorry to hear that. May I ask why?”
“It is one who shrinks from encountering Europeans, even holds
aloof from me. Though we work in the same field, we have rarely
met.”
Mark would have liked to have gleaned more particulars, but the
burly American missionary was not disposed to be communicative,
and all he could gather about his mysterious neighbour was, that the
individual was not a European, not a heathen, and not young.

CHAPTER XXXIX.
A FRIENDLY VISIT.
Captain Waring had departed for England without ceremony or
beat of drum (leaving his debts behind him), also presumably his
cousin, who had not had the common decency to leave P. P. C.
cards—no, not even on the mess or the club—and who had treated
poor Honor Gordon shamefully; indeed, several matrons agreed that
in the good old days such a man would certainly have been shot or
horsewhipped!
How Colonel Sladen had chuckled, surmised, and slandered, had
bemoaned the girl’s lost good looks, and her aunt’s idiotcy to all
comers, as he waited impatiently for his afternoon rubber! Next to his
whist, the relaxation he most thoroughly enjoyed was a bonâ fide ill-
natured gossip, with a sauce in the form of sharp and well-spiced
details.
No reliable information respecting Mr. Jervis had as yet been
circulated—for Clarence, on second thoughts, had kept his late
comrade’s plans and whereabouts entirely to himself.
Mrs. Brande knew, and held her tongue. What was the good of
talking? She was much subdued in these days, even in the colour of
her raiment. She rarely went to the club; she dared not face certain
questioning pitiless eyes in the awful verandah; indeed she kept in
the background to an unparalleled degree. Nevertheless she had her
plans, and was prepared to rise phoenix-like from the ashes of her
former hopes. She was actually contemplating a second venture, in
the shape of a niece. She thought Honor wanted cheering up, and a
face from home—especially such a lovely face—would surely have a
happy result. But Honor’s thoughts were secretly fixed upon another
countenance, a certain colourless, handsome face—a face she
never expected to see again. Her mind dwelt with poignant

memories on a pair of eyes, dim with wordless misery, that had
looked into her own that hateful June morning.
“We can well afford it, P.,” urged his wife, apropos of her scheme.
“One girl is the same as two—one ayah between them.” She little
knew Fairy.
“Please yourself,” cried Mr. Brande, at last; “but Honor shall
always be my niece, my chief niece, and nothing shall ever put her
nose out of joint with her uncle Pelham.”
“No one wants to! I should like to see any one try that, or with me
either. But what a nose Fairy has! Just modelled to her face like a
wax-work.”
Mrs. Brande talked long and enthusiastically to Honor about her
sister. But Honor was not responsive; her eyes were averted, her
answers unsatisfactory; indeed, she said but little, and looked
positively uncomfortable and distressed. And no doubt she felt a wee
bit guilty because she had prevented the child from coming out
before. But that was very unlike Honor; Mrs. Brande could not
understand it.
How she would exult in a niece who was a miracle of loveliness,
instead of being merely a pretty, bright, and popular girl. Not that
Honor was very bright now; she was losing her looks, and Honor’s
love affair had come to such a woeful end. Honor was not the sort of
girl to take up with any one else; and, indeed, she could not wonder.
Poor Mark! of all her boys, he was the one nearest to her heart.
Still she considered that he had carried filial love a great deal too
far, when she had thought over his sacrifice in moments of cool
reflection. It was a shame that Mark, and Honor, and a magnificent
fortune should all be sacrificed to an eccentric old hermit.
Mrs. Brande said little; she was not receiving the support and
encouragement she expected. She placed Fairy’s photograph in
poor Ben’s silver frame in a conspicuous place in the drawing-room,
and she mentally sketched out the rough draft of another letter to
Hoyle.

Before this letter took definite shape, Mrs. Langrishe came to call
—a dinner “call”—in full state and her best afternoon toilet. Seating
herself on the sofa, she began to tell Mrs. Brande all about her dear
invalid, exactly as if she were talking to a most sympathetic listener
—instead of to a deadly rival.
“He is such a nice man, and so quiet in a house.”
“For that matter,” retorted Mrs. Brande, “he is quiet enough out of
the house, and everywhere else.”
“And he is so contented and easily amused,” continued Mrs.
Langrishe. “I left him with Lalla reading aloud to him.”
“Do you think that is quite the thing?” inquired Mrs. Brande, with a
dubious sniff.
“Why should she not do it as well as hospital nurses?” demanded
her visitor.
Mrs. Brande reflected on the result of her own nursing. Would this
nursing have the same effect?
“Hospital nurses are generally young, single, and very frequently
pretty,” resumed Mrs. Langrishe. “They read to their patients, and
take tea with them, and no one says a word. All the difference
between them and these girls is, their uniform and their experience;
and surely no one ever dreams of making a remark about those
excellent, devoted young women!”
Lalla was not excellent, but she had certainly been most devoted
—as her aunt thankfully acknowledged.
“Well, I don’t know that I should allow Honor to do it,” said Mrs.
Brande, with a meditative air.
“Possibly not. It would, of course, depend upon circumstances.
Now”—laying two fingers playfully on Mrs. Brande’s round arm—“I
am going to be a little bird, and whisper a little secret in your ear.”
Mrs. Brande drew back, as if she thought Mrs. Langrishe was
going to be a little rattlesnake.

“It is not to be given out for a few days, but Lalla and Sir Gloster
are engaged. It is quite settled.”
Sir Gloster had only proposed the previous evening, and had
begged that the fact of the engagement might be kept quiet for a
week, until he had wired home to his all-important mother. She must
be told before any one. Yes, he had succumbed to Lalla’s bright
blandishments. He was a dull, heavy man; he liked to be amused.
He would have amusement all day long when Lalla was his wife. She
had a charming voice, and read aloud well. She brought him all the
scraps of news, she was an admirable mimic, an adroit flatterer, and
altogether a charming girl; and her daily tête-à-têtes were of a most
stimulating character, and he looked forward to them with keen
anticipation. She gave him a capital description of the unmasking of
Captain Waring, the sensation created by the soi-disant poor
relation; how every one was certain that it was going to be a match
between him and Miss Gordon; how he had absconded, and Miss
Gordon was left. He had evidently joined his friend in Bombay—wise
young man!
Sir Gloster, who was naturally of a huffy and implacable
disposition, had never recovered the shock to his affections and self-
esteem. He was by no means sorry to hear that in her turn Miss
Gordon had been spurned, and he was resolved to show her how
speedily he had been consoled.
Mrs. Langrishe, when she entered Mrs. Brande’s house, had not
intended to divulge her great news—merely to throw out hints, draw
comparisons, and trample more or less on the fallen and forsaken.
But for once human nature was too strong for her: she would have
had a serious illness if she had not then and there relieved her mind
of her overwhelming achievement.
Mrs. Brande opened her blue eyes to their widest extent; her worst
fears were confirmed.
She however mustered up an artificial smile, and said—
“I am sure you are very pleased,” which was true—“and I am glad
indeed to hear it,” which was not true.

“It is to be kept quiet for a week,” murmured Mrs. Langrishe; “but I
am telling you as an old friend, who I feel sure will be pleased with
the news. Of course, we are all delighted; it is everything we could
wish,” and she drew herself up.
“I should rather think it was!” rejoined Mrs. Brande, tartly; she was
but human after all.
“My brother and all my people will be much gratified—Sir Gloster
is such a dear good fellow, and so well off, and so steady.”
“I hope he won’t be a little too steady for Lalla!”
“Not he; and he delights in all her fun, and singing——”
“And dancing?” suggested Mrs. Brande, significantly.
“It will not be a long engagement,” ignoring this little thrust. “This is
the second week of September; we shall all be going down in
another six weeks. We will have the wedding in about a month.”
It was on the tip of Mrs. Brande’s tongue to say, “Delays are
dangerous,” but she closed her lips.
“Where is Honor?” inquired Mrs. Langrishe, with rare effusion.
“She has gone off down the khud to get ivy for the table. I have a
small dinner this evening.”
“You are always having dinners, you wonderful woman.”
“Well, you see, in Pelham’s position, we must entertain, and I
make it a rule to have a dinner once a week.”
“You are quite a providence to the station!” cried her visitor
affectedly. “How pretty those grasses are. I suppose Honor arranged
them? What a useful girl she is!”
“Yes, she takes all trouble off my hands. I don’t know how I shall
ever get on without her.”
“How lucky for you, that there is no chance of her leaving you! My
dear, that was a most unfortunate affair about Mr. Jervis.”

“What do you mean?” inquired Mrs. Brande, whose crest began to
rise.
“Oh,” with a disagreeable laugh, “it is what did he mean! He paid
Honor the most devoted attention, and the moment he was revealed
in his true colours—he fled. No one knows what has become of him.”
“Pardon me—we do!” returned his champion, with a quiver of her
double chin.
“And—where is he, dear? what is he doing?”
“He is doing a good—a noble action. Putting himself and his
wishes aside for the sake of others,” returned Mrs. Brande in a white
heat of emotion.
“Oh well,” rather disconcerted, “if you and Honor, and above all Mr.
Brande, are satisfied, of course there is no more to be said——”
“No,” pointedly. “I hope no more will be said. Have you seen the
photograph of my other niece, Honor’s sister?” making a desperate
effort to rally and change the conversation, and reaching for the
frame, which she solemnly placed in Mrs. Langrishe’s hand.
“What do you think of her?” Here at least she was certain of
scoring a small triumph.
“Think, my dear woman! Why, that she is perfectly lovely.” (It was
safe to praise a girl who was in England.)
“At first she was coming out to me,” her aunt pursued, “but she
changed her mind. Now we are thinking of having her out in
November with the Hadfield’s girl.”
“Indeed,” said Mrs. Langrishe, reflectively, and still nursing the
picture, as it were, on her knee.
She had a wonderful knack of picking up odd bits of news, and her
brain contained useful little scraps of the most promiscuous
description. Her mind was a sort of ragbag, and these scraps often
came in appropriately. She rummaged out a scrap now.
She had recently heard, from a cousin of hers (an artist), of a Mrs.
Gordon, a widow with two daughters, one of them lovely, who was

sitting to him as Rowena—an ideal Rowena—but who was also a
dwarf—a sort of little creature that you might exhibit.
“Does your niece live at Hoyle, and is her name Fairy?”
“Yes. Why do you ask?” rather eagerly.
“I have heard of her, recently, from my cousin, Oscar Crabbe. And
why did she not come out?” looking at her with a queer smile.
“Her health was not very good—and there was some other reason
—which I have not been told.”
“I know the reason, and can tell you, if you like,” said Mrs.
Langrishe, with an air of affectionate confidence.
Here was an unexpected opportunity of planting a dart in her
adversary’s side.
“There is no object in keeping the matter secret, it is just as foolish
as that scheme of young Jervis’s, who was like an ostrich sticking his
head in the sand. By the way, it appears that that is quite an
exploded idea! Every one in Hoyle knows Miss Fairy Gordon’s
appearance—she is extraordinary lovely—but——”
“But not mad? Don’t say she is mad!” protested Mrs. Brande,
excitedly.
“No, no; not so bad as that. But,” looking steadily into her listener’s
eyes, she added, “poor little creature, she is a dwarf! She never grew
after she was ten, I am told. Yes, it is a dreadful pity,” gazing into her
hostess’s horrified countenance. “Sitting down, she is just like other
people—but when she stands up, she seems to have no legs.”
“A dwarf! No legs! And she thought of coming to me! And I was
just going to write and ask her to start in November,” repeated Mrs.
Brande in gasps.
“Well, my dear, it is a most fortunate circumstance that your letter
has not gone. What could you have done with her? You could never
have taken her out except after dark.”
This was a terribly effective thrust. Mrs. Brande was wholly unable
to retaliate, and made no reply.

“A dwarf!” Her mind conjured up a little fat sallow woman, such as
she had once seen outside a show at a fair, and that miserable
stunted native who was carried about Shirani, begging, on the
shoulders of a boy.
And her niece, of whose picture she was so proud, that she had
placed it in a solid silver frame—her lovely niece was like that!
“I wonder Honor never told me,” murmured Mrs. Brande at last.
“And I do not,” was the emphatic rejoinder. “From all accounts, the
mother and sisters have always spoiled the little one, who believes
that she is in no way different to other people, and is too ridiculously
vain. Even if she had been five foot six, I am sure that you are far
happier without her,” concluded Mrs. Langrishe, rising and squeezing
her hostess’s hand as she spoke. And having offered this small
fragment of consolation, she rustled away.
Mrs. Brande, poor woman, had been indeed trampled upon, and
crushed to the very earth. She had been asked to join in her rival’s
song of triumph over Miss Paske’s superb success; she had been
condoled with on her own dear girl’s misfortunes; and she had been
informed that she was aunt to a dwarf!
She sat for some time in a shattered, stupefied condition; then she
got up, and hastily carried off Fairy’s photograph and locked it away
in a box, secure from all eyes, and from even the ayah’s inquisitive
brown fingers.
Honor noticed the absence of her sister’s picture from its usual
post of honour—it was nowhere to be seen—the absence of Fairy’s
name in conversation, the sudden cessation of all interest in Gerty
Hadfield’s movements, and guessed rightly that some one had kindly
enlightened her aunt, and that she was in possession of the other
reason now.

CHAPTER XL.
THE NEW WEARER OF THE CORNELIAN RING.
Six weeks had crawled by. With all his occupation Mark found time
desperately hard to kill; he felt as if he had lived his present life for at
least six years. The monsoon had broken, and on some days the
torrents compelled him to remain indoors; and whilst sheets of rain
and hurricanes of wind swept the valley, an appalling loneliness
settled down upon the miserable young man. His father passed
many hours in sleep, and he had not a soul with whom to exchange
a word. One evening, during a welcome break, he was riding
homewards down a steep and slippery path that wound through wet
dark pine-woods, when his pony suddenly shied so violently as
almost to lose its footing; he had taken fright at an undefined object
beside the road, something which at first his rider mistook for a bear,
until it emitted a groan of unmistakable human anguish.
“What is the matter?” asked Jervis, as he quickly dismounted.
“Alas, I have hurt my foot!” replied a female voice in Hindostani. “I
fell down—I cannot walk.”
Jervis threw the bridle over his arm, lit a match, and, shading it
with his hand, saw, huddled up, what appeared to be an old native
woman. She explained to him, between groans and gasps, that she
had twisted her ankle over a root on the path, and could not move.
“Are you far from home?” he inquired.
“Three miles.”
“In which direction?”
“The hill above the old cantonment.”
“I know. If you think you can sit on my pony, I will lead him and
take you home safely.”

“Oh, I am such a coward,” she cried. “Is the pony gentle?”
“Yes, he is all right; I will answer for the pony.”
“I—and I cannot bear pain. Oh—oh! but I must”—vainly struggling
to rise, and sinking down again.
She proved a light weight, as Jervis raised her bodily in his arms,
and placed her in the saddle. Fortunately the pony, who bore the
suggestive name of “Shaitan,” was too much sobered by a long
journey to offer any active opposition to carrying a lady. The
homeward progress proved exceedingly tedious; the road was bad
and nearly pitch dark. The native woman, who appeared to know
every yard of the way, directed her companion by a path almost
swallowed up in jungle, to a hill behind the old mess-house. Up and
up they climbed, till they came to a tiny stone bungalow, with a light
in the window. The door was thrown open by another native woman
and an old man, whose shrill voluble lamentations were almost
deafening.
“You had better let me carry you in?” suggested Jervis.
“No, no.” Then imperiously to the other woman, “Anima, bring
hither a chair and help me down.”
But Anima, of the lean and shrivelled frame, had been set a task
far beyond her strength, and in the end it was the muscular arms of
the young Englishman that lifted the other from the saddle. As he
placed her carefully on the ground, her shawl, or saree, fell back,
and the lamplight revealed a fair-skinned woman with snow-white
hair, and a pair of magnificent black eyes. She was possibly fifty
years of age—or more—and though her lips were drawn with pain,
she was remarkably handsome, with a high-bred cast of
countenance. No native this; at any rate, she resembled no native
that Jervis had ever seen. Who was she?
A glance into the interior surprised him still further; instead of the
usual jumble of cooking-pots, mats, and hookahs, he caught a
glimpse of a round table, with a crimson cover. A newspaper, or what
looked like one, lay upon it; there was an armchair, a fire blazing in a
fireplace, with a cat sedately blinking before it.

Who was this woman? He was not likely to learn any further
particulars—at present, for she was helped in by her two servants;
and as he waited, the door was abruptly closed and barred, and he
was left outside, alone in the cold and darkness. Here was gratitude!
He rode slowly home, the pony figuratively groping his way, whilst
his master was lost in speculation. This was the mysterious
neighbour, he felt certain; this was the tender of the graves—the
owner of the voice.
He related his adventure to his father whilst they played picquet.
Major Jervis was not half as much surprised as the young man
had anticipated—he simply stroked his forehead, a favourite trick of
his, and said, with his eyes still fastened on his cards—
“Oh, so you have come across the Persian woman! I so seldom
hear of her, I had forgotten her.”
“Persian?”
“Yes. She has been in these hills for years, working among the
lepers. A fair-skinned woman, with great haunting dark eyes.”
“But who is she?” throwing down his cards and looking eagerly at
his father.
“She is what I tell you,” impatiently—“a Persian; they are generally
fair, and I dare say she has been handsome in her day, about thirty
years ago. Why are you so interested?”
“Because I have another idea in my head; I believe she is an
Englishwoman.”
The major’s laugh was loud, and sound, and not at all mad.
“She is a Persian—only, of course, you are no judge—and to the
very tips of her fingers.”
“But what is she doing up here?”
“I would rather you asked her that than I did,” was the extremely
sane reply. “She is a Christian, I believe, and is working out her sins.

I have no doubt she is a woman with a past. You can read it in her
eyes. Come, my boy, take up your hand; it’s your turn to play.”
Mark Jervis, as we know, had not been permitted time or
opportunity to read anything, whether referring to past or present, in
the Persian’s eyes; but this omission was corrected ere long.
One afternoon he noticed a figure, stick in hand, resting on the
mess-house steps, as he rode by—a figure which raised the stick,
and imperatively summoned him to approach.
It was undoubtedly his recent acquaintance, who pulled the veil
further over her head, as she said—
“Sahib, I wish to thank you for your charitable benevolence. Truly,
but for you, I should have lain all night in the forest, in the rain, and
among the beasts.”
“I hope you are better?” he asked, doffing his cap.
“Yea, nearly well. Though I am a stranger to you, I know that you
are Jones Sahib’s son.”
“Major ‘Jervis’ is his real name. Yes—I am his son.”
“I have heard of you,” she continued, rather loftily.
“Indeed!”
“From the leper-folk,” she added, significantly.
“It is you who keep the graves yonder in order?”
“May be!” was her cautious reply.
“And who sing English hymns in the old church?”
A slight contraction passed over her face as she replied—
“Nay—I am a Persian woman from Bushire. What should I know of
thy songs or thy tongue?”
“Then who—can it be?” inquired Jervis, looking at her steadfastly.
“Noble youth—why ask me? A woman from the dead, perchance,”
she retorted mockingly.

“At least, it is you who do so much good among the sick Pahari-
folk and lepers?” he persisted.
“Yea, I am but one—the field is great. Who can fill jars with dew? I
would I could do more.”
“I believe that were hardly possible.”
“As far as these hands go,” extending a pair of delicately-shaped
members, “I do what I can; but what is one lemon for a whole village
to squeeze! If I had a big house that would serve as a hospital, I
should have my heart’s desire. I am skilled in medicine, so also is my
servant; we would have our sick beside us, and could do much—that
is my dream. It will never come to pass till the sun shall be folded up
and the stars shall fall.”
“Surely one of these bungalows would answer. Why not this mess-
house?” suggested Jervis generously.
“True; but the sircar would not yield it to me. Already the sircar has
given me my abode; and, doubtless, were I to ask for the Mess
Khana, they would aver that I was like to the man who, on receiving
a cucumber, demanded a tope of mango trees! Moreover this dead
station may reawaken once more. Even in my memory the merry
sahibs and mem sahibs have sojourned here, and held great
tamashas; but it is years since they came, and the place, perchance,
is forgotten.”
“And so you have lived here alone—for years?” said the young
man. His remarkably expressive eyes distinctly added the “Why?” his
tongue refrained from uttering.
“Yea, I have been dead to the world and the roar of strife and life
for many moons! If all tales be true—tales whispered even in this
empty land—you have forsaken many delights to give your days to
the old man, your father? Is it not so?” She looked up with a quick
gesture, and her saree fell back.
As Jervis gazed down into the dark eyes turned towards him, he
agreed with his father; here was undoubtedly a woman with a past—
and a tragic past!

“It is a noble sacrifice,” she continued; “but what saith the Koran?
‘Whatever good works ye send on for your behoof, ye shall find them
with God.’ I am old enough to be your mother. I marvel if I had had a
son, would he sacrifice himself thus for me—were I of your people, a
Feringhee woman, I marvel?” she repeated meditatively, as she put
up her hand to draw her veil further over her head.
As she did so, the young man started as he recognized her ring—
Honor’s cornelian ring. Many a time he had noticed it on her finger,
and her peculiar trick of turning it round and round, when in any
mental quandary, had been the subject of more than one family jest.
How came it to be on the hand of this Mahommedan woman?
She instantly interpreted his glance, and exclaimed—
“You observe my ring. Truly it is of little value—in money—but to
me it is beyond price. It was given to me by a maiden I saw but once.
Her words were pearls, her lips were rubies, but her music, and her
eyes, drew the story of my life from my inmost soul.”
“I am sure I know the lady!” cried her listener impetuously, “young
—and tall—and beautiful. She plays what you call the sitar. Where
did you meet her?”
“Ah, sahib, that is my secret,” she answered after an expressive
pause; “but, lo! I can reveal yours,” and she looked at him steadily as
she added, “you love her.”
“What do you mean?” he stammered. “Why do you say so?” and
he coloured up to the roots of his crisp brown hair.
“Of a truth, I read it in your face. It is not for naught that folk call
me a magic wallah.” And she rose stiffly to depart. “You have
abandoned her, I see,” she continued, with a flash of her wonderful
eyes, “and lo, the fat old mem sahib, her mother, will marry her to
some one else! Behold your reward, for doing your duty!” And
entirely forgetting her previous quotation from the Koran, with this
unpleasant and cynical remark, the Persian made him a profound
salaam, and hobbled away.

CHAPTER XLI.
“IT WAS A HYENA.”
The rains were over by the middle of August, and Shirani cast off
mackintoshes, discarded umbrellas, and society—restless and
fluctuating—looked about for some fresh and novel form of out-door
amusement.
Among the second-leave arrivals, the most active and enterprising
of the new-comers, was a Captain Bevis, the moving power in
whatever station he was quartered; the very man for getting up
dances, races, and picnics. He was resolved to strike out an entirely
original line on the present occasion, and inaugurated a grand joint
expedition into the interior—none of your exclusive “family parties,”
or a petty little “set” of half a dozen couples. No, this sanguine
individual actually proposed to move Shirani en masse. He had
heard of the abandoned cantonment, of Hawal Bagh, galloped over
to inspect it with his customary promptitude, and came flying back to
the station on the wings of enthusiasm. “It was a perfect spot,” this
was his verdict; scenery exquisite, good road, good water, lots of
bungalows, a mess-house to dance in, a parade ground for
gymkanas. Every one must see the place, every one must enjoy a
short informal outing, the entertainment to be called the “Hawal Bagh
week.” Captain Bevis threw himself into the project heart and soul;
he invited another hill station to join; he sent out circulars, he
collected entries for gymkanas and polo matches, and the names of
patronesses for the grand ball at Hawal Bagh. Dead and long-
forgotten Hawal Bagh, that was to awake and live once more!
Subscriptions poured in, parties went over to explore, empty
houses were allotted, a vast army of coolies was enlisted, the jungle
was cut down, the bungalows cleaned up, the very gardens were put
in order. A quantity of supplies and cart loads of furniture were soon
en route, and the servants of Shirani entered into the project with the

Welcome to our website – the ideal destination for book lovers and
knowledge seekers. With a mission to inspire endlessly, we offer a
vast collection of books, ranging from classic literary works to
specialized publications, self-development books, and children's
literature. Each book is a new journey of discovery, expanding
knowledge and enriching the soul of the reade
Our website is not just a platform for buying books, but a bridge
connecting readers to the timeless values of culture and wisdom. With
an elegant, user-friendly interface and an intelligent search system,
we are committed to providing a quick and convenient shopping
experience. Additionally, our special promotions and home delivery
services ensure that you save time and fully enjoy the joy of reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!
ebookgate.com

PDF JavaServer Pages 2nd Edition Larne Pekowsky download

More Related Content

Similar to PDF JavaServer Pages 2nd Edition Larne Pekowsky download (20)

Recently uploaded (20)

PDF JavaServer Pages 2nd Edition Larne Pekowsky download