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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script
- SuperTuxKart 0.9.2 Released
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