Home arrow Java arrow 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
(Page 1 of 7 )

The first part of this article introduced you to JavaServer Pages, their elements, and how to deploy web applications in J2EE and Tomcat. This article concludes the chapter.

JSP Initialization and End-of-Life

In the JSP lifecycle section above, I mentioned that you can add methods to your JSP that will be called when the JSP is initialized and when the JSP is destroyed. These methods are declared using the declaration scripting element.

When you need to perform one-time initialization of the JSP, you would add this method to the JSP:

public void jspInit() {
// ...perform one time initialization.
// ...this method is called only once per JSP, not per

If you need to clean up any resources used by the JSP, you would add this method to the JSP:

  public void jspDestroy() {
    // ...perform one time cleanup of resources

If you dont need to perform initialization or cleanup, you do not need to add these methods to the JSP.

Implicit Objects

The previous section stated that the properties of a JavaBean can be set from the parameters in the request sent by the client browser. Your JSP can also access the clients request directly. You access the clients request through an object named request. In addition to the request object, the JSP model provides you with a number of other implicit objects. These objects are implicit because a JSP has access to and can use them without needing to explicitly declare and initialize the objects. Implicit objects are used within scriptlet and expression elements. In this section, we will look at these implicit objects:

  • request
  • response

  • out

  • session

  • config
  • exception
  • application


In this section, I will show the methods of these objects that you will be using the most. You should consult the Javadoc for the complete list and explanation of all the available methods.

The request Object

JSP pages are web components that respond to and process HTTP requests. The request implicit object represents this HTTP request. Through the request object, you can access the HTTP headers, the request parameters, and other information about the request. You will most often use this object to read the request parameters.

When a browser submits a request to a server, it can send information along with the request in the form of request parameters. These take two forms:

  • URL-encoded parametersThese are parameters appended to the requested URL as a query string. The parameters begin with a question mark, followed by the name-value pairs of all the parameters, with each pair delimited by an ampersand (&):

  • Form-encoded parameters These parameters are submitted as a result of a form submission. They have the same format as URL-encoded parameters, but are included with the body of the request and not appended to the requested URL.

These parameters can be read through various methods of the request object:

  String request.getParameter(String name);
  String[] request.getParameterValues(String name); 
  Enumeration request.getParameterNames();
  Map getParameterMap();

The getParameter(String) method returns the value of the parameter with the given name. If the named parameter has multiple values (for example, when a form submits the value of checkboxes), this method returns the first value. For multi-valued parameters, getParameterValues(String) returns all the values for the given name. The getParameterNames() method returns all the parameter names used in the request, while getParameterMap() returns all the parameters as name-value pairs.

Information can also be passed to the server using extra path information. This data is appended to the requested URL. For example, suppose /Ch03/MyComponent was the context and name of a web application component; additional information could be appended to the path like this: Ch03/MyComponent/extraPathInfo. With the correct configuration, the server would send the request to MyComponent, and MyComponent would get the extra path information using this method:

  String request.getPathInfo();

The request object has request scope. That means that the implicit request object is in scope until the response to the client is complete. It is an instance of javax.servlet.HttpServletRequest. For further information about the methods of request, see Chapter 5.

The response Object

The response object encapsulates the response to the web application client. Some of the things you can do using the response are set headers, set cookies for the client, and send a redirect response to the client. You can perform those functions with these methods:

  public void addHeader(String name, String value)
  public void addCookie(Cookie cookie)
  public void sendRedirect(String location)

It is an instance of javax.servlet.HttpServletResponse and it has page scope.

The out Object

The out implicit object is a reference to an output stream that you can use within scriptlets. Using the out object, the scriptlet can write data to the response that is sent to the client. For example, we could rewrite the earlier welcome.jsp to use the out object like this:

Iterator categories = faqs.getAllCategories();
while (categories.hasNext()) {
String category = (String)categories.next();
      out.println("<p><a href=\"" + replaceUnderscore
  (category) + "\">" +
                   category + "</a></p>");

The scriptlet above would cause the same HTML to be sent to the client as was sent in the original version of welcome.jsp. Note that one of the purposes of JSP is to separate the HTML from the Java code, so the above example is not the best use of the out object.

The out object is an instance of javax.jsp.JspWriter. It has page scope.

The session Object

HTTP is a stateless protocol. As far as a web server is concerned, each client request is a new request, with nothing to connect it to previous requests. However, in web applications, a clients interaction with the application will often span many requests and responses. To join all these separate interactions into one coherent conversation between client and application, web applications use the concept of a session. A session refers to the entire conversation between a client and a server.

The JSP components in a web application automatically participate in a given clients session, without needing to do anything special. Any JSP page that uses the page directive to set the session attribute to false does not have access to the session object, and thus cannot participate in the session.

Using the session object, the page can store information about the client or the clients interaction. Information is stored in the session, just as you would store information in a Hashtable or a Hashmap. This means that a JSP page can only store objects in the session, and not Java primitives. To store Java primitives, you need to use one of the wrapper classes such as Integer, or Boolean. The methods for storing and retrieving session data are:

  Object setAttribute(String name, Object value);
  Object getAttribute(String name);
  Enumeration getAttributeNames();
  void removeAttribute(String name);

When other components in the web application receive a request, they can access the session data that was stored by other components. They can change information in the session or add new information to it. Also, be aware that sessions are not inherently thread-safe. You should consider the possibility that two or more web components could access the same objects from the same session simultaneously. If this could be a problem for your application, you must synchronize access to the objects stored in the session.

Normally, you dont need to write code in your page to manage the session. The server creates the session object, and associates client requests with a particular session. However, this association normally happens through the use of a cookie that is sent to the client. The cookie holds a session ID; when the browser sends the cookie back to the server, the server uses the session ID to associate the request to a session. When the browser does not accept cookies, the server falls back to a scheme called URL rewriting to maintain the session. If there is the possibility that the server will be using URL rewriting, your page needs to rewrite any embedded URLs. This is actually done with a method of the response object:


The second method is used when the URL will be sent as a redirect to the browser using the response.sendRedirect() method. The first method is used for all other URLs.

The session object has session scope, and all the objects stored in the session object also have session scope. The session object is an instance of javax.servlet.http.HttpSession.

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