JavaServer Pages

This month Reuven discusses JSPs, which allow programmers and nonprogrammers alike to create servlets and dynamic pages with a mix of Java and HTML.

Last month, we took a first look at server-side Java, sticking our toes into the water by writing some servlets. Servlets are Java programs that produce dynamic web content. CGI programs are executable programs external to the web server that execute from scratch each time they are invoked. By contrast, Java servlets live inside a servlet container, a Java virtual machine (JVM), that is closely connected to an HTTP server. Whenever the web server needs dynamic content, it makes a request from the servlet container.

In many ways, writing a Java servlet is like writing a mod_perl handler: it gives you a great deal of power, but also requires a fair amount of discipline. It can also be frustrating to write a servlet that is 90% static HTML and 10% Java, and the number of times that you invoke out.println() can become maddening.

An increasingly popular solution to this problem is JavaServer Pages or JSP. JSP is similar in spirit to Microsoft's ASP, as well as to the open-source PHP language and Mason component system. JSP allows you to mix Java with HTML in a number of different ways. The fact that JSPs, like most Java programs, are remarkably platform-independent, means you can write JSPs on a Windows box, run them on a development Linux server and then deploy them on Solaris.

This month, we will take a quick look at JSPs, which are a good way to get to learn Java as well as an easy way for Java programmers to create servlets without having to work too hard.

How JSPs Work

The idea behind JSPs is remarkably simple: they are servlets in disguise. When a JSP is first invoked, it is automatically turned into a servlet. This servlet is then complied into a Java .class file, which is then executed inside of the servlet container. The first time a JSP is invoked, it will take a little bit longer to return data to the user, due to all the action taking place behind the scenes.

In a JSP, everything is assumed to be static content unless it is placed inside special braces, <% and %>. These tags are known as “scriptlets” in JSP lingo. The following HTML file (which we will name main.jsp) is also a perfectly legitimate JSP:

<HTML>
   <Head>
      <Title>Static JSP Title</Title>
   </Head>
   <Body>
      <P>Static JSP Content</P>
   </Body>
</HTML>

The above JSP is rather boring in that it consists exclusively of static content. But the JSP engine doesn't care how many pieces of dynamic content a JSP contains; it will turn the entire thing into a servlet regardless of its complexity. In the case of the above JSP, the resulting servlet will be little more than a long string of out.println() statements inside of the doGet() method.

On my system, I saved the above HTML into main.jsp in the examples directory that comes with Tomcat /usr/java/jakarta-tomcat-3.2.1/webapps/examples/jsp/. This is admittedly not the best place to install it, but it is the easiest.

Once I've installed the JSP, I don't need to do anything else; the system will automatically translate it into a servlet source (.java) file, and then compile it into a Java .class file.

We can execute and view our JSP via the Tomcat server, which operates by default on port 8080, http://localhost:8080/examples/jsp/main.jsp/.

If you've configured Apache and mod_jk to forward servlet and JSP queries to Tomcat, then you should also be able to view main.jsp with this URL: http://localhost/examples/jsp/main.jsp/.

On my system, the .java and .class files generated by the JSP system for main.jsp are in the directory: /usr/java/jakarta-tomcat-3.2.1/work/localhost_8080%2Fexamples. If I list the contents of this directory, I see the following:

_0002fjsp_0002fmain_0002ejspmain.class
_0002fjsp_0002fmain_0002ejspmain_jsp_0.java
_0002fjsp_0002fmain_0002ejspmain_jsp_1.java
_0002fjsp_0002fmain_0002ejspmain_jsp_2.java
_0002fjsp_0002fmain_0002ejspmain_jsp_3.java
_0002fjsp_0002fmain_0002ejspmain_jsp_4.java
_0002fjsp_0002fmain_0002ejspmain_jsp_5.java
_0002fjsp_0002fmain_0002ejspmain_jsp_6.java

As you can see, there are seven different .java files, each corresponding to a different version of the original JSP. Each time I modify the JSP, the system must create a new .java file. The Tomcat default keeps previous versions of the JSP-based servlet around; however, there can only be one .class file at a given time, which is clearly the case in this directory.

The names of the .java and .class files are quite long and aren't meant to be entered directly into a web browser. Part of the magic of JSPs is that Tomcat can find the servlet associated with a given URL intelligently and automatically, creating the Java source file as necessary.

You should take a look at the Java source code created by the JSP translator so that you can get a feel for the hard work being done behind the scenes. Our simple, static JSP has been turned into a servlet that takes up more than 100 lines of Java source code. In case we ever have to debug our JSPs from the translated servlet source code—a difficult task, as anyone who has used Perl's HTML::Mason can attest—the servlet includes comments that provide a basic mapping from the line numbers in the original JSP to those in the resulting servlet.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

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

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

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

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

Learn More

Sponsored by Storix