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.
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.
Fast/Flexible Linux OS Recovery
On Demand Now
In this live one-hour webinar, learn how to enhance your existing backup strategies for complete disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible full-system recovery solution for UNIX and Linux systems.
Join Linux Journal's Shawn Powers and David Huffman, President/CEO, Storix, Inc.
Free to Linux Journal readers.Register Now!
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- July 2016 Issue of Linux Journal
- Tibbo Technology's Tibbo Project System
- Client-Side Performance
- Sony Settles in Linux Battle
- Libarchive Security Flaw Discovered
- Peppermint 7 Released
- Profiles and RC Files
- Git 2.9 Released
- Snappy Moves to New Platforms
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide