The JSP Files (Part 1) - Purple Pigs in a Fruitbasket

The JSP Files (part 1): Purple Pigs In A Fruitbasket
By Vikram Vaswani and Harish Kamath
This article copyright Melonfire 2000−2002. All rights reserved.
Table of Contents
The JSP Story......................................................................................................................................................1
Studying The Foundations.................................................................................................................................2
Java In A Teacup................................................................................................................................................3
Enter John Doe....................................................................................................................................................6
Putting Two And Two Together........................................................................................................................8
Basket Case........................................................................................................................................................10
Alphabet Soup For The Soul............................................................................................................................13
The JSP Files (part 1): Purple Pigs In A Fruitbasket
i
The JSP Story
Ever since Sun Microsystems (aka "the dot in dot−com") came up with Java, the geeks have been screaming
themselves hoarse about the wonders of this technology. Terms like "platform−independent code" and "write
once, run anywhere" have been given so much airplay that even novice Java developers are aware of them,
and the language is also popular with talk−show pundits and Internet consultants, who tout it as the solution to
almost all problems of cross−platform compatibility.
Now, we're big fans of Java − we've used it in the past, and will do so again in the future − but this series of
tutorials isn't about Java. It's actually about an offshoot of Java, the innocuously−named Java Server Pages, or
JSP, which attempts to offer Web developers a compelling alternative to traditional server−side scripting
languages like Perl, PHP and ASP.
How? First, a little history...
During the early days of the Web, it was the sheer amount of (free!) content that encouraged people to use it.
Using the easy−to−learn HTML language, any one and their deaf grandma could set up a Web page and reach
out to other like−minded souls online. As the infrastructure improved, content was no longer restricted to text;
you could now view pictures or watch videos on the Web. And as more and more people began adding
interactivity to their Web sites, a bunch of programming languages were born in order to meet increasingly
complex requirements.
The best−known of these is, of course, Perl, although PHP and ASP are also popular favourites. The problem

with these languages, however, is that every request to the Web server for a Web page generates a new
process on the server, leading to performance problems as visitor traffic increases.
Java offers a solution to this problem, by using so−called "servlets" to create interactive Web sites (a Java
servlet is like a Java applet, except that it runs on the Web server, not the client Web browser − and if you're
confused now, wait till we get to scriptlets). Java also makes it possible for brick−and−mortar companies to
interface their legacy systems with the new technologies available on the Web, and rapidly develop and link
back−office automation systems together via the Internet.
However, servlets have a problem of their own − a simple interface or logic modification could often result in
far−reaching changes to the servlet. And so, JSP was developed to separate application logic from the
interface, so that changes to one would not affect the other. Working closely with developers like The Apache
Group, JSP uses a tag−based approach (similar to PHP and ASP) which allows designers to make changes to
the user interface without affecting application logic.
If you're wondering about scalability, JSP supports component−based architectures using JavaBeans or
Enterprise JavaBeans; this allows a developer to create reusable code modules and thereby speed up
development time. And since this is Java, you can seamlessly connect Web applications to legacy systems,
thereby reducing the costs of moving a real−world business into cyberspace. Say it with us − platform
independence rocks!
The JSP Story 1
Studying The Foundations
JSP is based on a multi−tier architecture, which can best be explained by comparing it to the architecture seen
on non−JSP sites (read: PHP− or ASP−driven sites). In the typical Apache/PHP/mySQL architecture, you
have a Web server and a database server at one level, with a scripting language like PHP taking care of the
communication between the two to churn out dynamic content. While this kind of architecture is fine for sites
that attract a middling amount of traffic, it begins to display its warts when traffic increases and the load on
the database and Web servers goes up.
The JSP architecture, on the other hand, involves more than one level, immediately making it more scalable
and maintainable.
In case you're wondering what the long words mean, scalable implies that you can easily increase, or "scale
up", your systems as traffic increases, while maintainable implies that it is possible to simply modify one part
of the system − changing over from one database to another, for example − without affecting other areas.

In the context of JSP, a multi−tier architecture involves the Web server for static HTML content, the
application server for JavaBeans and servlets, and the database server for database connectivity. Additionally,
you can combine JSP with JavaBeans and Java servlets to create complex Web applications which build upon
previously−released and tested code modules, thereby simplifying code maintenance and increasing
reusability.
It is important to note here that JSP code is not read line−by−line, as with PHP; it is first converted into a
servlet (a bytecode version of the program) and then invoked by a servlet engine (such as Tomcat) to perform
the required actions. Once the servlet is executed, the results are sent back to the client. Since the servlet
engine has to compile the servlet the first time around, displaying a JSP page can take a little while the first
time you access it; however, the next time around, response time will be dramatically reduced, since the
servlet will have already been compiled and therefore ready for immediate use.
Studying The Foundations 2
Java In A Teacup
In order to begin working on JSP, you need to get yourself copies of Sun's Java Development Kit, Apache's
httpd Web server and mod_jserv module, and the Tomcat servlet engine, and configure them so that they're all
working together. This tutorial assumes that you've got a JSP development environment set up − in case you
don't, take a look at "Slapping Together A JSP Development Environment" at , a tutorial which will guide you
through the process.
With that out of the way, let's get down to the nitty−gritty of actually creating a JSP page. Open up a new file
in your favourite text editor and type in the following lines of code:
<html>
<head>
</head>
<body>
<%
// asking for it!
out.println("Waiter, can I have a cup of Java, please?");
%>
</body>
</html>

Save this file with the extension .jsp − for example, "coffee.jsp" − in an appropriate location and then view it
by pointing your browser to it − for example, http://localhost/jsp/coffee.jsp . You should see something like
this:
<html>
<head>
</head>
<body>
Waiter, can I have a cup of Java, please?
</body>
</html>
</font>
And that, grasshopper, is your first scriptlet!
In JSP−lingo, a "scriptlet" is a block of code executed by the JSP engine when the user requests a JSP page.
All scriptlets are enclosed within <%...%> tags (similar to ASP and PHP code), like this:
Java In A Teacup 3
<%
... JSP code ...
out.println("Waiter, can I have a cup of Java, please?");
... JSP code ...
%>
Every JSP statement ends in a semi−colon − this convention is identical to that used in Perl, and omitting the
semi−colon is one of the most common mistakes newbies make. Just as an example, here's what happens
when you omit the semi−colon from the example above:
Error: 500
Location: /jsp/coffee.jsp
Internal Servlet Error:
org.apache.jasper.JasperException: Unable to compile class:
Invalid type
expression.
out.println("Waiter, can I have a cup of Java, please?")

^
: Invalid declaration.
out.write("\r\n\r\n\r\n");
^
2 errors
at org.apache.jasper.compiler.Compiler.compile(Compiler.java,
Compiled
Code)
at
org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:462)
at
org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader12.java:146)
at
org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:433)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(JspSe
rvlet.java:152)
at
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
va:164)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:318)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java,
Compiled
Code)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
The JSP Files (part 1): Purple Pigs In A Fruitbasket
Java In A Teacup 4