Home arrow Java arrow Page 4 - JavaServer Pages, conclusion

JavaServer Pages, conclusion

If you've taken a look at J2EE and JavaServer Pages technology, and want to examine JSP more closely, you've come to the right place. This article is the second of two parts, excerpted from chapter three of Beginning J2EE 1.4 From Novice to Professional, written by James L. Weaver, Kevin Mukhar, and Jim Crume (Apress, 2004; ISBN: 1590593413).

Author Info:
By: Apress Publishing
Rating: 4 stars4 stars4 stars4 stars4 stars / 17
November 10, 2005
  1. · JavaServer Pages, conclusion
  2. · The config Object
  3. · Try It Out: Using JavaBeans in JSP Pages
  4. · Translation and Compilation
  5. · The Deployment Descriptor
  6. · Including and Forwarding from JSP Pages
  7. · Summary

print this article

JavaServer Pages, conclusion - Translation and Compilation
(Page 4 of 7 )

As you develop and test JSP pages, you may have noticed that the first time you access a new page, there is some delay before the page is sent to the browser. This is a result of the server translating and compiling the page at request time. After the page has been translated and compiled, subsequent requests to the page are processed more quickly.

The Servlet API

When a page is translated, whether at request time, or earlier, it is translated into a Java source file. This Java class is known as a servlet. You may have noticed the term servlet earlier in the chapter. Much of what a JSP does is based on the Servlet API, another API within J2EE. In fact, the Servlet API predates the JSP API.

Servlets were developed to allow a servers capabilities to be extended by Java code that ran inside the server. HttpServlets are servlets that run inside an HTTP server. A servlet accepts HTTP requests from clients, and creates dynamic responses to those requests. It sends response data to the client through an OutputStream. The servlet uses a session object to store data about a client and the clients interactions with the server. The servlet has access to the application through a ServletContext object, and it can access servlet parameters through a ServletConfig object. In fact, all the features of JSP pages that we will see in this chapter are based on the servlet model.


So, if servlets can do everything JSP pages can do, why do we need JSP?

If a JSP page is an HTML page with bits of embedded code, a servlet is Java code with bits of HTML. However, the larger the web application, the more HTML tends to be in the Java code. This becomes very hard to maintain, especially if your team has web experts who are not programmers.

Servlets tend to be good at computations and processing, while JSP pages tend to be good at data presentation. If only there were a way to get all the HTML out of servlets, and all the Java code out of JSP pages. That way, programmers could work on the servlets, and web designers could develop the JSP pages. In the next chapter, we will see one way to move the code out of JSP pages.

So, although you dont need to be a servlet expert to work with JSP, if you know how servlets work it can help to understand what is happening with the page. Well look at servlets in detail in Chapter 5.

A Translated JSP

Lets take a quick look at a translated JSP to see how the JSP page is translated into code that implements a Java servlet. Most servers will keep the translated .java source file in the file system, so you can examine it if you need to. For J2EE 1.4, that location is J2EE_HOME\domains\{domain}\server\generated\jsp\j2ee-apps\{app name}\war-ic_war\ where J2EE_HOME is the appropriate location of the J2EE installation on your system, {domain} is the domain name used when you start your server (domain1 is the default), and {app name} is the name of the application. For the Tomcat stand-alone, that location is TOMCAT_HOME\work\Standalone\localhost\application_context, where TOMCAT_HOME is the appropriate location of the Tomcat installation on your system. If you have deployed the examples in this chapter, navigate to the appropriate directory and open the source file for the welcome.jsp page. The J2EE reference implementation and Tomcat both name the source file as welcome_jsp.java. If you are using a different server, the name may be different. We will not look at every line in the file, but only some of the lines that show the relation between the JSP source and the Java source. For this section, I looked at the welcome_jsp.java source file created by Tomcat 5.0 for the last Try It Out example. Your Java source file may differ, depending on which server you have and which source file you are looking at.

One of the first things you will notice is that the import attribute of the page directive has been turned into import statements:

  import java.util.Iterator;
  import ch3.*;

This is followed by the class statement:

  public final class welcome_jsp
      extends org.apache.jasper.runtime.HttpJspBase
      implements javax.servlet.jsp.el.FunctionMapper,

Notice that the class extends HttpJspBase. In the servlet chapter, we will see that servlets in a web application extend HttpServlet.

Next, you will see that the two declarations in the JSP page have been turned into a variable declaration and a public method declaration in the Java source. Note that the variable is declared as a member variable of the class, and so is accessible from all the methods in the class:

  FaqCategories faqs = new FaqCategories();
public String replaceUnderscore(String s) {
    return s.replace(' ','_');

The main body of the JSP is contained in the _jspService() method as shown here. In the Servlet API, the analogous method is service(). This method starts by declaring the implicit objects that are used when servicing a request. Of course, they are not so implicit now that the translator has added the code to declare and initialize them:

  public void _jspService(HttpServletRequest request, 
                  throws java.io.IOException,
  ServletException {
JspFactory _jspxFactory = null;
    javax.servlet.jsp.PageContext pageContext = null;
    HttpSession session = null;
    ServletContext application = null;
    ServletConfig config = null;
    JspWriter out = null;
    Object page = this;
    JspWriter _jspx_out = null;

Following the previous code is code that initializes all the implicit objects. Although we will not explicitly look at all the code in this chapter, I do want to show one last snippet from the _jspService() method:

  out.write("<body>\n   ");
  out.write("<h1> Java FAQ Welcome Page");
User user = (User) session.getAttribute("user");
if (user == null) {
out.write("\n    You are not yet registered, please
  \n   ");

This is part of the code that outputs the template data to the client. Notice that the translated code uses the same implicit out object that the JSP can use. Also, notice that the whitespace from the JSP source file is preserved in the Java source file. A servlet implementing the same page would similarly output the HTML template data using print statements. However, with a servlet, you would need to code those statements manually. With a JSP page, it is much easier to write the template data as HTML, and let the container perform the translation to Java code.

Earlier in the chapter, I stated that you could declare and define a jspInit() method and a jspDestroy() method. If you define those methods in the JSP, they will appear as additional methods in the Java source file.

Errors and Exceptions

If youve typed in any of the examples in this chapter, or if you have created any JSP pages of your own, you have probably run into the situation where youve had bugs in your page. Whether these bugs occur at translation time or at request time affects the response that you see in the browser when you attempt to test your page. Sometimes you see a very ugly stack trace. Well, maybe not ugly to you, as the developer, but you dont want any of the users of your application to see anything so unfriendly.

Java web applications can deal with exceptions in a number of ways. Obviously, some exceptions can be handled as you develop the web application by adding data validation and try-catch blocks into the code. This technique avoids the exceptions. However, you need a way to deal with unexpected exceptions. Two ways to deal with unexpected exceptions are through:

  • The page directive


  • The deployment descriptor


The page Directive

We have already seen how to include a page directive in your JSP page. The page directive can have an attribute named errorPage. Whenever an uncaught exception occurs in that particular page, the server sends the specified error page to the client. This allows you to use different error pages for different components in the application. The errorPage attribute looks like this:

  <%@ page errorPage="/WEB-INF/errorPage.jsp" %>

where the value of the errorPage attribute is the path to the error page file. The drawback is, of course, that you can only specify a single error page for all exceptions in the JSP page.

blog comments powered by Disqus

- Java Too Insecure, Says Microsoft Researcher
- Google Beats Oracle in Java Ruling
- Deploying Multiple Java Applets as One
- Deploying Java Applets
- Understanding Deployment Frameworks
- Database Programming in Java Using JDBC
- Extension Interfaces and SAX
- Entities, Handlers and SAX
- Advanced SAX
- Conversions and Java Print Streams
- Formatters and Java Print Streams
- Java Print Streams
- Wildcards, Arrays, and Generics in Java
- Wildcards and Generic Methods in Java
- Finishing the Project: Java Web Development ...

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 

Developer Shed Affiliates


© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials