J2EE Spell

J2EE Servlets & JSP ======================================================================================================================== === Chapter: 1 JAVA AND THE J2EE PLATFORM Topics Discussed Introduction Enterprise Today System Architecture 2-Tier Architecture 3-Tier Architecture n-Tier Architecture Enterprise Architecture Is Java the Answer? Platform Independence Reusability Modularity The J2EE Platform J2EE Architecture – Containers 1.1 Introduction Java, as a programming language is still young. However, the evolution of Java from a means of developing applets for running in browsers, to a programming model capable of driving today’s’ enterprise applications has been remarkable. Java has been around for only five years, yet it has attracted a very high level of interest in the technical and business communities, fuelling a considerable range of applications. From its inception, Java has triggered new programming models and technologies in different domains – ranging from devices, to telephony applications, to the enterprise. At the same time, Java has acted as a catalyst in making certain technology domains take more robust and secure shapes. Java’s enterprise computing platform, a.k.a. the Java 2 Platform, Enterprise Edition (J2EE) is one such domain. There were times in the history of Java, when debates on whether Java is a programming language or a platform used to surface in the media as well as technical circles. However, J2EE is one of the most successful attempts by Sun and its associates at making Java credible as a platform for enterprise computing. 1

Transcript of J2EE Spell

Page 1: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================


Topics Discussed

Introduction Enterprise Today System Architecture 2-Tier Architecture 3-Tier Architecture n-Tier Architecture Enterprise Architecture Is Java the Answer? Platform Independence Reusability Modularity The J2EE Platform J2EE Architecture – Containers

1.1 Introduction

Java, as a programming language is still young. However, the evolution of Java from a means of developing applets for running in browsers, to a programming model capable of driving today’s’ enterprise applications has been remarkable. Java has been around for only five years, yet it has attracted a very high level of interest in the technical and business communities, fuelling a considerable range of applications.

From its inception, Java has triggered new programming models and technologies in different domains – ranging from devices, to telephony applications, to the enterprise. At the same time, Java has acted as a catalyst in making certain technology domains take more robust and secure shapes. Java’s enterprise computing platform, a.k.a. the Java 2 Platform, Enterprise Edition (J2EE) is one such domain.

There were times in the history of Java, when debates on whether Java is a programming language or a platform used to surface in the media as well as technical circles. However, J2EE is one of the most successful attempts by Sun and its associates at making Java credible as a platform for enterprise computing.

But what is J2EE? Why is it relevant? Why should you choose this technology for building enterprise-level application – from client-server to Internet to mobile? This chapter gives one perspective, and assists you in answering these questions. We hope that the rest of this book will help you to successfully build and manage such applications.

In this introductory chapter, we’ll focus on

The J2EE technical architecture

What makes J2EE credible as a platform

What are the challenges it addresses


Page 2: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

What technologies constitute the J2EE platform

First however, let us start with the challenges of developing applications for the enterprise today.

1.2 The Enterprise Today

With the advent of the Internet, many businesses realized that a whole new market had opened up to be exploited, however, we doubt if many had realized what a radical effect it would have on the economy. Through the Internet and the recent growth of e-commerce, an organization’s information assets have now become more valuable. This shift to an information economy is forcing many businesses to rethink even their most basic business practices. In order to maintain a competitive edge, the adoption of new technologies has become a key factor in a company’s ability to best exploit its information assets. More importantly, adapting these new technologies to work in tandem with the existing, legacy systems has become one of the foremost requirements of the enterprise.

One place these shifts in business practices have been felt most keenly is at the application development level. The funding and the time allocated to application development have been shrinking, while demands for complexity have increased. Although the emphasis on information is a small hurdle for developers, the whole revolution is being driven by the rapidly changing technological and economic landscape, which has created some new challenges for today’s enterprise application developers:

ResponsivenessAlthough timeliness has always been important, the high-placed, fast-changing information-driven economy means that responding quickly to new directions and information is critical in establishing and maintaining a competitive edge.

Programming ProductivityDirect adoption of new technologies is insufficient unless they are properly utilized to their full potential and appropriately integrated with other relevant technologies. Thus, the ability to develop and then deploy applications as effectively and as quickly as possible is also important. Achieving this can be complicated by the sheer variety of technologies and standards that have been developed over the years, requiring highly developed skill sets, the acquiring of which and keeping up with which is a problem in itself. Moreover, the rapid pace of change in `standards’ themselves poses significant challenges to ensuring efficient meshing of technologies.

Reliability and AvailabilityIn today’s Internet economy downtime can be fatal to the success of a business. The ability to get your web-based operations up and running, and to keep them running, is critical to success. As if that wasn’t’ enough, you must also be able to guarantee the reliability of your business transactions so that they will be processed completely and accurately.

SecurityThe Internet has not only exponentially increased the number of potential users but also the value of a company’s information, thus the security of that information has become of prime concern. What’s more as technologies become more advanced, applications more sophisticated,


Page 3: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

and enterprises more complex, the ability to implement an effective security model become increasingly difficult.

ScalabilityThe ability for the application to grow to meet new demand both in its operation and user base is important when an application’s potential user base may be millions of individual users through the Internet. To scale effectively requires not only the ability to handle a large increase in the number of clients but also effective use of system resources.

IntegrationAlthough information has grown to be a key business asset, much of this information exists as data in old and outdated information systems. In order to maximize the usefulness of this information, applications need to be able to integrate with the existing information system – not necessary an easy task as current technologies have often advanced far ahead of some of these legacy systems. The ability to combine old and new technologies is key to the success of developing for today’s enterprises.

None of these problem domains is especially new to the enterprise developer! But solving these problems in a comprehensive and economical manner is still crucial. You may be aware that there have been several technologies to address one or more of the above demands. However, what has been missing is a comprehensive platform with a rich infrastructure and numerous architectural possibilities that also promotes a rapid development environment.

1.3 System Architecture

When discussing enterprise application development, it is appropriate to introduce the concept of n-tier architecture. Typical client/server systems are based on the 2-tiered architecture, whereby there is a clear separation between the data and the presentation/business logic. These are generally data driven, with the application existing entirely on the client machine while the database server is deployed somewhere in the organization. While this approach allows us to share data across the enterprise, it does have many drawbacks.

1.3.1 2-Tier Architecture

In a traditional 2-tiered application, the processing load is given to the client PC while the server simply acts as a traffic controller between the application and the data. As a result, not only does the application performance suffer due to the limited resources of the PC, but the network traffic tends to increase as well. When the entire application is processed on a PC, the application is forced to make multiple requests for data before even presenting anything to the user. These multiple database requests can heavily tax the network.




Page 4: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Another problem, with a 2-tiered approach is that of maintenance. Even the smallest of changes to an application might involve a complete rollout to the entire user base. Even if it’s possible to automate the process, you are still faced with updating every single client installation. What’s more, some users may not be ready for a full rollout and ignore the changes while another group insists on making the changes immediately. This can result in different client installation using different versions of the application.

1.3.2 3-Tier Architecture

To address these issues, the software community developed the notion of a 3-tier architecture. An application is broken up into three separate logical layers, each with a well-defined set of interfaces. The first tier is referred to as the presentation layer and typically consists of a graphical user interface of some kind. The middle tier, or business layer, consists of the application or business logic and the third tier – the data layer – contains the data that is needed for the application.

The middle tier (application logic) is basically the code that the calls upon (through the presentation layer) to retrieve the desired data. The presentation layer then receives the data and formats it for display. The separation of application logic from the user interface adds enormous flexibility to the design of the application. Multiple user interfaces can be built and deployed without ever changing the application logic, provided the application logic presents a clearly defined interface to the presentation layer.

The third tier contains the data that is needed for the application. This data can consist of any source of information, including an enterprise database such as Oracle or Sybase, a set of XML documents (data that has been stored in documents conformant to the XML specification), or even a directory service like an LDAP server. In addition to the traditional relational database storage mechanism, there are many different sources of enterprise data that your applications can access.

However, we’re not quite finished with our subdivision of the application. We can take the segregation one final step to create an n-tier architecture.


User Interface

Application Logic


Page 5: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

1.3.3 n-Tier Architecture

As the title suggests, there is no hard and fast way to define the application layers for an n-tier system. In fact, an n-tier system can support a number of different configurations. In an n-tier architecture the application logic is divided by function rather than physically.

n-tier architecture then breaks down like this:

A user interface that handles the user’s interaction with the application; this can be a web browser running through a firewall, a heavier desktop application or even a wireless device

Presentation logic that defines what the user interface displays an dhow a user’s request are handled – depending own hat user interfaces are supported you may need to have slightly different versions of the presentation logic to handle the client appropriately

Business logic that models the application’s business rules, often through the interaction with the application’s data.

Infrastructure services that provide additional functionality required by the application components, such as messaging, transactional support, etc.

The data layer where the enterprise’s data resides.


Applications based on this architecture are employing the Model-View-Controller (MVC) pattern. What this ultimately means is that the data (the model) is separated from how the information is presented (the view). In between this is the application/business logic (the controller) that controls the flow of the information. Therefore, an application is designed based on these three functional components (model, view, and controller) interacting with each other.



Application Client

Presentation Logic

Business Logic Service


Page 6: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

1.3.4 Enterprise Architecture

So far we have really been concentrating on a single application’s architecture, however, we are in danger of considering these application as ‘stovepipes”. In other words, we might end up with many different applications – possibly even with different architectures – all of which don’t communicate with one another. In an enterprise, we are looking to create a more cohesive whole.

Rather than a change in architecture – enterprise architecture is basically just n-tier – we need a change in perception. To turn an n-tier system into an enterprise system, we simply extend the middle tier by allowing for multiple application objects rather than just a single application. These application objects must cash have an interface that allows it to work together with the others.

An interface can be thought of as a contract. Each object states through its interface that it will accept certain parameters and return a specific set of results. Application objects communicate with each other using their interfaces:

With enterprise architecture, we can have multiple applications using a common set of components across an organization. This promotes the standardization of business practices by creating a single set of business functions for the entire organizations to access. If a business rule changes, then changes have to be made to the business object only and, if necessary, it’s interface and subsequently any object that accesses the interface.

It is important to note that when designing an object and its interface, it is a good idea to make the interface as generic as possible to avoid changes later on. Since other objects communicate with the interface and not the object itself, changes to the object, and not the interface, are relatively simple and quick.



Remote Systems

Database Middleware

InterfaceApplication component

InterfaceApplication component

InterfaceApplication component


Page 7: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

1.4 Is Java the Answer?

So far we have discussed system architecture from an implementation agnostic perspective and there exist many potential paths that you can take to actually implement your enterprise. Microsoft has Windows DNA (and the new.net architecture), Sun has J2EE, Oracle has the Oracle 8i Internet Platform, and so on. With so many choices for server-side development, you are probably wondering what makes Java such a great choice.

1.4.1 Platform Independence

With a enterprise’s information spread disparately across many different platforms and applications it is important to leverage a programming language that can work equally well throughout the enterprise without having to resort to awkward, inefficient translation mechanisms. A unifying programming model also reduces the difficulties encountered from integrating many of the different technologies that grow up specific to certain platforms and applications.

1.4.2 Reusability

Code reuse is the holy grail of all programming. Segregating an application’s business requirements into component parts is one way to achieve reuse; using object-orientation to encapsulate shared functionality is another. Java uses both. Java is an object-oriented language and, as such, provides mechanisms for reuse. However, unlike objects, components require a more complex infrastructure for their construction and management. Basic object oriented concepts do not provide such a framework; however, the Enterprise Edition of Java provides a significantly stringent architecture for the reuse of components.

1.4.3 Modularity

When developing a complete server-side application, your programs can get large and complex in a hurry. It is always best to break down an application into discreet modules that are each responsible for specific task. When you do this, it makes your application much easier to maintain and understand Java servlets, JavaServer Pages, and Enterprise JavaBeans provide ways to modularize your application - breaking your application down into tiers and into tasks.

Despite the above features in its favor, it was not until early 2000 that Java developed a unifying programming model for applications on the enterprise scale – not that it lacked the capabilities but rather it was disorganized. Sun recognized this shortcoming and released the Java 2 Platform, Enterprise Edition (J2EE).

The idea behind the J2EE platform is to provide a simple, unified standard for distributed applications through a component-based application model.

1.5 The J2EE Platform

As you’ll see in the rest of this book, J2EE is one of the best solutions that we’ve had so far for meeting the demands of today’s enterprise. J2EE specifies both the infrastructure for managing your applications, and the service APIs for building them.

The J2EE platform is essentially a distributed application server environment – a Java environment that provides the following:


Page 8: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

A runtime infrastructure for hosting applications. A set of Java extension APIs to build applications

The applications that you can develop with the above may be programs to drive web pages, or components to implement complex database transaction, or even Java applets – all distributed across the network.

1.6 J2EE Architecture – Containers

As discussed in the previous section, a typical commercial J2EE platform includes one or more containers. But what’s a container? A J2EE container is a runtime to manage application components, and to provide access to the J2EE, APIs. Beyond the identity associated with the runtime, J2EE does not specify any identity for containers. This gives a great amount of flexibility to achieve a variety of features within the container runtime.

This architecture shows two containers:

A web container for hosting Java servlets and JSP pages

An EJB container for hosting Enterprise JavaBean components

Apart from these two, the J2EE also specifies two more containers - an applet container to run applets, and an application client container for running standard Java application clients. In this book, our focus is limited to web and EJB containers only.

In the above figure, the vertical blocks at the bottom of each container represent the J2EE APIs. Apart from access to these infrastructure-level APIs, each container also implements the respective container-specific API (Java Servlet API for the web container, and the EJB API for the EJB container).

The stacks of rectangles (servlets, JSP pages, and EJBs) in this figure are the programs that you develop and host in these containers. In the J2EE parlance, these programs are called application components.The following figure shows the architecture of J2EE.



Page 9: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

So we can also say that a container is a Java 1.2 (Java 2 Standard Edition 1.2) runtime for application components.

In this architecture, there are primarily two types of clients.

Web clients normally run in web browsers. For these clients, the user interface is generated on the server side as HTML or XML, and is downloaded and then rendered by the browsers. These clients use HTTP to communicate with web containers. Application components in web containers include Java servlets and JSP pages. These components implement the functionality required for web clients. Web containers are responsible for accepting requests from web clients, and generating responses with the help of the application components.

EJB clients are applications that access EJB components in EJB containers. There are two possible types of EJB clients. The first category is application clients. Application clients are stand-a-alone applications accessing the EJB components using the RMI-HOP protocol. The second category of application clients is components in the web container. That is, Java servlets and JSP pages can also access the EJB components via the RMI-HOP protocol in the same way as the application clients.

In either case, clients access application components via the respective container. Web clients access JSP pages and Java servlets via the web container, and EJB clients access the EJB components via the EJB container.


J2EE Application Server

Databases and Other Resources


Java Servlets

JSP Panes


EJB ContainerWeb Container



Page 10: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Chapter: 2


Topics Discussed

Introduction to Servlets Why use Servlets? Resources for Writing Servlet The Servlet Architecture Servlet Lifecycle Creating a Simple Servlet Development Phases of J2EE Applications Development Phases of J2EE Applications The Servlet API Handling HTTP Requests

2.1 Introduction to Servlets

The evolution of Internet has led to the development of the Java language. It serves as a complete client/server solution where programs are dynamically downloaded onto the client. Till date, the focus has been on the client-side development of applets and GUI components, which is incomplete as far as client-server computing is concerned. Therefore, in this chapter, you will be introduced to the other side of the client/server computing – the Servlets.

Servlets are programs that run on a Web server and build Web pages on the fly. Building Web pages on the fly is useful (and commonly done) for a number of reasons:

The Web page is based on data submitted by the user. For example the results pages from search engines are generated this way, and programs that process orders for e-commerce sites do this as well.

The data changes frequently. For example, a weather-report or news headlines page might build the page dynamically, perhaps returning a previously built page if it is still up to date.

The Web page uses information from corporate databases or other such sources. For example, you would use this for making a Web page at an on-line store that lists current prices and number of items in stock.

A servlet can be thought of as a server-side applet. Servlets are loaded and executed by a Web server in the same manner as the applets are loaded and executed by a Web browser. A servlet accesses requests from the client, performs some task, and returns results.The following are the basic steps of using servlets: The client makes a request. The Web server forwards the request to the servlet after receiving it from the

client. Some kind of process is done by the servlet after receiving the request. A response is returned back to the web server from the servlet.


Page 11: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The web server will forward the response to the client.

Figure 2.1 shows how a web server processes a request and the response sent to the client. Request


Fig. 2.1Working of a servlet

The security issues, as associated with applets, are not applied with servlets because servlets are executed on the server and if you Web server is secure behind a firewall, then your servlets is secure as well.

2.2 Why use Servlets?

Servlets have various benefits over other technologies that are used for writing server side programs. One such technology is CGI (Common Gateway Interface) scripts. Servlets have less start-up cost, they run continuously, and they are platform-independent. The following section distinguishes between Servlets and CGI-based Web programs in detail.

The CGI program that handles the request for the server is terminated as soon as the request is processed whereas Servlets continue to run even after the request is processed. This eliminates the heavy start-up overhead. The CGI program must store the information in a database or a file and read it again the next time it starts up when it needs to maintain information across the network. There is heavy start-up overhead for this reason.

You have to create different versions of plug-ins for running the same CGI program on a different hardware platform or a different operating system. Servlets can run on any platform that supports Java.

Different levels of security can be allowed for different servlets by taking advantage of Java’s security framework. For example, a security policy, which allows a servlet to access only certain directories on your file system, can be defined. CGI programs do not have a basic security framework, but rely instead of on a collection of ad hoc rules. 2.3 Resources for Writing Servlet

You have to install JavaSoft’s Java Servlet Development Kit (JSDK) before creating any servlet. This kit includes the Java servlet and Sun servlet packages, sample services for Windows 95 and NT, and ServletRunner to test servlets.

You have to set the environment variable CLASSPATH, to the required location so that your servlets can find the servlet packages. The following environment variable need to be set for Windows systems, with the JSDK installed in the C:\2sdk:

Classpath: c:\j2sdk\j2sdk.jar;Path: c:\j2sdk\bin;

The JSDK can be downloaded from the JavaSoft home page (http://java.sun.com). The Java Servlet Development Kit is included as a part of JDK 1.2. If you are still using JDK 1.1 you should download the JSDK 1.0.1 separately.



Web Server


Page 12: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

To run Servlets, you need a Web server that supports the Servlet API. We will be using J2EE (Java 2 Enterprise edition 1.2.1) to run servlets. There are various other vendors that are providing server implementations for this purpose. Some of them are given in Table 2.1.

Vendor ProductApache Apache jservATG Dynamo Application ServerCybotics Cybotics Search EngineIBM Internet Connection ServerKonaSoft KonaSoft Enterprise ServerLotus Domino Go WebserverNovocode NetForge Web ServerO’Reilly Website ProfessionalTandem iTP WebserverW3C Jigsaw HTTP ServerWebLogic Tengah Application Server

Table 2.1List of products supporting Java Servlets

The following steps are required to run any servlet:

1. If your Web server is not running, start it.2. Configure the Web server to install the servlet.3. Run your browser.4. Direct the browser to the particular URL that refers to the new servlet.

Another thing to remember while creating servlets is that you need to create some kind of client application that invokes the servlet. This client application can be provided in form of HTML or applets. We will be developing our applications using HTML. While HTML is lightweight and is supported by Java enabled web browsers, applets are beneficial as they solve the portability and distribution problems. We will be using both HTML and applets to communicate with servlets.

2.4 The Servlet Architecture

There are various interfaces and classes that are used to implement a simple servlet. Let us discuss some of them that are essential for working of a servlet.

The Servlet Interface

All servlets implement the Servlet interface, either directly or by extending a class that implements it such as GenericServlet. The Servlet interface provides methods that manage the servlet and its communications with clients. While developing a servlet, you need to provide implementations for all or some of these methods. For example, the init () and destroy() methods are used to start and stop a servlet. The service() method is invoked by the server so that the servlet can perform its services. It takes two parameters one of the ServletRequest interface and the other of the ServletResponse Interface.

Service/Response and ServletRequest Interface

When a servlet accepts a call from a client, it receives objects from the ServletRequest and ServletResponse interfaces. The ServletRequest interface encapsulates the communication from the client to the server, while the


Page 13: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

ServletResonse interface encapsulates the communications from the servlet back to the client.

The ServletRequest interface allows the servlet access to information such as the names of the parameters passed in by the client, the protocol (scheme) being used by the client, and the names of the remote host (getRemoteHost () method) that made the request and the server that received it. It also provides the servlet with access to the input stream, ServletOutputStream, through which the servlet gets data from clients that are using application protocols such as the HTTP POST and PUT method. Subclasses of ServletRequest allow the servlet to retrieve more protocol-specific data. For example, HttpServletRequest contains methods for accessing HTTP-specific header information.

The ServletResponse interface gives the servlet methods for replying to the client. It allows the servlet to set the content length and mime type of the reply, and provides an output stream, ServletOutputStream, and a Writer though which the servlet can send the reply data. Subclasses of ServletResponse give the servlet more protocol-specific capabilities. For example, HttpServletResponse contains methods that allow the servlet to manipulate HTTP-specific header information.

The classes and interfaces described above make up a basic Servlet. There are various other methods that are used to give additional capabilities to a servlet. A detailed explanation of these classes and interfaces is given later in the chapter.

2.5 Servlet Lifecycle

Servlets run on servers as we have discussed earlier. Let us now see how a servlet is loaded and run on a web server. When a server loads a servlet, it runs the servlet’s init method. The server calls the init method once, when it loads the servlet, and will not call it again unless it is reloading the servlet.

The server cannot reload a servlet until after it has removed the servlet by calling the destroy method. Initialization is allowed to complete before client requests are handled (i.e. before the service method is called) or the servlet is destroyed.

After the server loads and initialize the servlet, the servlet is able to handle client requests. It processes them in its service method. Each client’s request has its call to the service method run in its own servlet thread: the method receives the client’s request, and sends the client its response.

Servlets can run multiple service methods at a time.

Servlets run until they are removed from the service, for example, a request of a system administrator. When a server removes a servlet, it runs the servlet’s destroy method. The method is run once; the server will not run it again after it reloads and reinitializes the servlet. The servlet lifecycle is given in Figure 2.2.


Page 14: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================



Fig. 2.2The Servlet Lifecycle

2.6 Creating a Simple Servlet

The basic steps required for writing servlets are as follows:

Step 1: Extend the GenericServlet class. Step 2: Override the service() method. (The init() and destroy() methods are

not overridden to make the program simpler. The init() and destroy() methods are typically used when the program needs to initialize or release some resources.)

Step 3: Get the output stream from the ServletResponse object and create a PrintStream object with it.

Step 6: Finally, print the request string to the PrintStream.

Let us write a simple servlet program with the help of the above methods. This servlet will respond to the client with the server’s information.

import java.io.*;import javax.servlet.*;public class SimpleServlet extends GenericServlet{

public String getServletInfo( ){

return "Localhost ";}public void service(ServletRequest req, ServletResponse res){

try {PrintStream out = new PrintStream (res.getOutputStream() );out.println ("Hello "+ req.getRemoteHost());out.println ("The following is the information about the environment in which the servlet is running ");out.println ("The name of the server running is "+getServletInfo() );} catch (Exception e) {}


The above servlet extends the GenericServlet class and overrides the getServletInfo() and the service() method. The getServletInfo() method returns a string that provides information about the servlet. The service() method





Server Code

Server Code

Server Code



Handle Client Requests

Page 15: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

implements the actual request handling and response handling. The Web server invokes it when the URL of the servlet is requested. The server passes the ServletRequest and ServletResponse arguments to the servlet. The getRemoteHost() method returns the name of the host that made the request.

Save this file in the folder ServletExample. Compile it using the javac compiler as given below:

C:\ServletExample> javac SimpleServlet.java

Now let us write the HTML, which will invoke this servlet. The HTML is given below:

<html><head>Servlet Example</head><form Method = "GET" Action = "SimpleServletAlias" ><INPUT NAME= "Test" Type=SUBMIT VALUE="test"></input></form></html>

Save this file as Servlet.html in the folder ServletExample. The Action attribute of the Form tag takes the alias name of the Servlet. This is the alias name that should be provided while deploying the servlet using J2EE. We will see this while assembling the servlet.

2.7 Development Phases of J2EE Applications

The servlet that is created will be assembled and run on a J2EE server. As a J2EE application evolves, it passes through these development phases:

Web Component Creation J2EE Application Client Creation J2EE Application Assembly J2EE Application Deployment

The first two stages are already accomplished. The web component i.e. the servlet and the client application, i.e. the HTML file, have already been created. Now let us look a next stage of developing a J2EE application. This involves J2EE application Assembly and deployment. Figure 2.3 shows how a web component can be assembled in a J2EE application (.ear file) and then deployed on the server.

Assembly Deployment Phase Phase

Fig. 2.3J2EE application assembly and deployment

The Servlet API

The Servlet API was defined by Sun Microsystems for writing servlets. The package javax.servlet defines all the classes and interfaces associated with the Servlet SPI. Some of the interfaces defined inside the Servlet API are:


WebComponent(.WAR file)

J2EEApplication(.ear file)

J2EE Server

Page 16: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Servlet ServletContext ServletRequest ServletResponse

And the classes are:

ServletInputStream ServletOutputStream

To write servlets, the developer has to use the four interfaces to make the server comply with the servlet API and then use the server’s implementations of this interface along with the ServletInputStream, and ServletOutputStream classes. The following section describes the Servlet API classes and interfaces in detail.

The Servlet Interface and its Methods

The Servlet Interface allows the developer to create servlets by providing the necessary functions. This interface includes the methods listed in Table 2.2:

Method Descriptionpublic void service( ServletRequest req, ServletResponse res)

This method is used to service a single request from a client. This main purpose of the parameters is to access the input and output streams that are connected to the client browser.

public void init() This method is called by the system when the servlet is first loaded. It is basically used for general initialization of the servlet. The init () method might be called to reset the servlet after it has been used. Hence, you have to be careful that only initialization is performed in this init () method.

ServletContext getServletContext() This method gets a servletContext object that is associated with information about the environment in which the servlet is running.

ServletContext getServletContext() This method gets a servletContext object that is associated with information about the environment in which the servlet is running.

void log (String mesg) This method is used to log a message to the servlet log. Log is generally written into a directory called log under the server’s home directory. These log entries depict the accesses the Web server receives.

String getServletInfo() This method returns the information about the servlet, as a string.

Public void destroy() This method is used to release the servlet.

Table 2.2Servlet Interface Methods

The ServletRequest Interface


Page 17: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The ServletRequest interface defines methods, gets input streams from the client, collects the header information, and extracts path and query information from the requested URL. The header information defines general aspects of the connection. The precise set of headers will depend on the browser being used to issue the request. You can get the header information through some methods described later in this chapter. Table 7.3 lists the methods of this interface:

Method Descriptionint getContentLength()

This method is used to return the size of the input data to be supplied (in bytes). It returns –1 if the size is unknown.

String getContent Type()

This method is used to return a string that is associated with the MIME content type for the data that is to be sent to the servlet from the client browser. This method returns nil if the client has not specified the content type. The Content type depends on the browser. For instance, some browsers specify content types of text / plain to indicate that the data is of no special type. Some use content / unknown, and some use application / octet-stream.

String getProtocol() This method is used to return the protocol and version of a Web browser client. The returned string is of the form <Protocol/major-version>.<minor-version>.

String getParameter( String parameter-name)

This method is used to return the value of the parameter (Query string defined in the URL) associated with the name of the parameter passed as an argument to this method. For example, if an URL is given as; http: // localhost:8080 / servlets / Myservlet>mesg=Hello , the method call getParameter(“mesg”) would return the string value Hello.

Enumeration getParameterNames()

This method is used to return an enumeration of strings representing the names of the parameters defined in the URL. This method does not return the values associated with the parameters. To obtain the associated values, call the getParameter() method.

InetAddress getRemoteAddr()

This method is used to return the IP address of the client who sent the request.

String getRemoteHost()

This method is used to return the name of the host who made the request.

String getQueryString()

This method is used to return a string that represents only the query string part of the Servlet URL.

String getServerName()

This method is used to return a string that represents the host name of the server.

int getServerPort() This method is used to return an integer that represents the port number through which the request is received.

String getPathTranslated()

This method is used to return the path information that describes the path on the server machine from which the servlet was loaded.

String getHeader(String header_field)

This method is used to return the header information associated with the header_field. To obtain the header_field use the method getParameterNames().

ServletInputStream getInputStream()

This method returns the input stream for reading the request data.

Table 2.3 ServletRequest Interface Methods

The ServletResponse Interface

The ServletResponse interface methods that are used for getting an output stream directed at the client, setting the header information, sending errors to the


Page 18: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

client, and setting the status of the response. This interface allows you to send information to the client’s browser.

The response status can be set through a list of static integer variables defined by the ServletResponse interface. The following are the variables:


Table below lists the methods of ServletResponse interface:

Method DescriptionServletOutputStream getOutputStream()

This method is used to return the output stream for writing responses to the client browser.

void setContentLength(int length) This method is used to set the content length of the response.

void setContentType (String type) This method is used to set the content type for the response. The content types are the MIME types discussed earlier. (Refer note for more details about MIME).

void write-Headers() This method is used to write the status and message headers for the response to the output stream.

void setStatus (int status) This method is used to write the status and message headers for the response to the output stream.

void setStream (int status) This method is used to set the status code and a default message for the response.

void setHeader( String header_field, String header_value)

This method is used to set the value of a header field.

Table 2.4 ServletResponse Interface Methods.

Note: The MIME Types area allows you to manage the list of suffixes and MIME type mapping for the Web service. A MIME type is a way to determine the contents of a file; thus you can map an extension (such as ` wav’ ) to a particular MIME type (such as audio/x.wav) so that the Web service knows what type of file is being handled. The format of MIME type is Type/Subtype, which the file extension is mapped to. The type defines the generic file category (such as audio, image, etc.) and the subtype defines the exact type within the generic type (such as x-wav, jpeg, etc.).

The ServletContext InterfaceThe ServletContext interface allows you to find out information about the environment in which the servlet is running. Table 2.5 lists the methods through which you can find these details;


Page 19: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Method DescriptionString getServerInfo() This method is used to return a string

that represents the name and the version of the server running.

String getServlet() This method is used to return a string that represents the name of the servlet.

Enumeration getServlets() This method used to return an enumeration of all the available servlets in this context.

Table 2.5ServletRequest Interface methods

Since the basic Servlet interface is not protocol-specific, servlets are likely to use HTTP as the basis of their communication. The HttpServlet class, a class that implements the Servlet interface is provided to give additional support methods that are useful when handling this protocol.

The Servlet API provides two additional interfaces that can be used with the HttpServlet class. These interfaces are HttpServletRequest and HttpServletResponse, which extend the ServletRequest and ServletResponse interfaces described earlier.

Handling HTTP Requests

We have written a program by extending the GenericServlet class. Because most servlets are implemented on web services that use the HTTP protocol to interact with clients, the most common way to develop servlets is by extending the javax.servlet.http.HttpServlet class.The HttpServlet class extends the GenericServlet base class and provides a framework for handling the HTTP protocol. Because it is an abstract class, servlet writers must subclass it and override at least one method. The methods normally overridden are:

doGet, if HTTP GET requests are supported. Overriding the doGet method automatically also provides support for the HEAD and conditional GET operations.

doPost, if HTTP POST requests are supported. doPut, if HTTP PUT requests are supported. doDelete, if HTTP DELETE requests are supported. The lifecycle methods init and destroy, if the servlet writer needs to manage

resources that are held for the lifetime of the servlet. Servlets that do not manage resources do not need to specialize these methods.

getServletInfo, to provide descriptive information through a service’s administrative interfaces.

Notice that the service method is not typically overridden. The service method, as provided, supports standard HTTP requests by dispatching them to appropriate methods, such as the methods listed above that have the prefix “do”.

Let us write a program that extends the HttpServlet class and uses the ServletContext interface to get an object of the ServletContext (through getServletContext() method- refer Table 2.2) that provided information about the environment in which the servlet is running. We will also change the MME type in the setContentType() method to text/html (refer Table 2.4). Now the response given by the Web server will be in HTML text, which will be interpreted by the client browser. The method getServerInfo() (refer Table 2.5) is then used to display information about the server. The program is as follows:


Page 20: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

import java.io.*;import javax.servlet.*;import javax.servlet.http.*;

public class GetServlet extends HttpServlet{

public void doGet (HttpServletRequest req, HttpServletResponse res ){try{

ServletContext sc=getServletContext();PrintStream out = new PrintStream( res.getOutputStream());res.setStatus ( HttpServletResponse.SC_OK);res.setContentType( “text/html”);out.println(“<HEAD><TITLE> SimpleServlet Output </TITLE></HEAD.</BODY>”);out.println(“<h1> SimpleServlet Output </h1>”);out.println(“<P>This output is from GetServlet.”);out.println (“The name and version of the server running is “+sc.getServerInfo());out.println (“</BODY>”);out.close();

}catch(Exception e) { } }}

Write the HTML file for the above servlet similar to the one give in the last program. Remember to use the Get request for the Method attributed of the form tag and the Action name should be the same as the alias name provided while deploying the servlets in J2EE.

Compile the servlet and then deploy the servlet following the same steps as given before. The output produced is given in Figure 2.4:

Fig. 2.4Output of the program

Let us write another servlet that receives two parameters from the client, the Login name and the password and responds back to the client with a thanks message. This servlet overrides the doPost method and uses the getParameter() (refer Table 2.3) method to get the value of the parameter.


Page 21: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

import java.io*;import javax.servlet.*;import javax.servlet.http. *;import java.util.*;public class Servlet2 extends HttpServlet {

public void doPost (HttpServletRequest req, HttpServletResponse res)throws ServletException, IO Exception

{// first, set the “content type” header of the responseres.setContentType (“text/html”);

//Get the response’s PrintWriter to return text to the client.PrintWriter toClient = res.getWriter();//Open the file for writing the survey results.String LoginName = req.getParameter (“Login”);String pwd = req.getParameter (“pwd”);// Respond to client with a thank youtoClient.println(“<html>”);toClient.println(“<title>Thank you!</title>”)toClient.println(“Thank you for registering <br>”);toClient.println(“Your Login name is “ + LoginName );toClient.println(“</html>”);// Close the writer; the response is done.

toClient.close (); }}

The HTML for the above servlet is given below:

<html><head><title>Login Form</title></head>

<body><form action="testAlias" method="POST"><BR><BR>Login<input type=text name=Login ></BR><BR>Password <input type=password name=pwd><BR></BR><input type=submit value = Login><input type=reset value=Cancel></form></body></html>

Deploy the servlet and the HTML file using the J2EE server. Remember to give the Alias name as test1Alias as given in the HTML file here. Open the Web browser and type the URL. The HTML page as given in Figure 2.5 will be displayed.


Page 22: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Fig. 2.5The Login form

After you give the Login name and the password, click on the Login button. The following output will be displayed on the screen.

Fig 2.6 Response from the servlet

Chapter: 3


Topics Discussed

Session Management Session Tracking Cookies

3.1 Session Management

Data needs to be managed in case of multiple HTTP requests. As you know that unlike TCP, http is a stateless protocol. This means that HTTP does not maintain a


Page 23: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

connection to the server for the duration of a session. A session consists of requests that are made during a single browser invocation. In other words, a session starts when you open a browser and ends when you close it. For example, in case of a shopping system, the list of items that are in a customers cart should be maintained. In order to do this, the server should be able to distinguish clients from one another and also provide a way to store data for each individual client.

The Servlet API provides a powerful model for keeping track of session information. For tracking sessions, you need to identify each client session uniquely. This can be done by assigning an identifier to each client, storing that identifier with the client and then making the client provide that identifier with each HTTP request to the server.

3.2 Session Tracking

Session tracking is a mechanism that services use to maintains state about a series of requests from the same user (i.e. requests originating from the same browser) across some period of time.

To use session tracking,

Get a session (an HttpSession object) for a user. Store or get data from the HttpSession object. Invalidate the session (optional).

Obtaining a Session The getSession method of the HttpServletRequest object returns a user’s session. When you call the method with it’s create argument as true, the implementation creates a session if necessary.

To properly maintain the session, you must call getSession before any output is written to the responses. (If you respond using a Writer, then you must call getSession before accessing the Writer, not just before sending any response data.)

Storing and Getting Data from a Session The HttpSession interface provides methods that store and return:

Standard session properties, such as a session identifier Application data, which is stored as a name-value pair, where the name is a

String and the value is an object in the Java programming language. (This is like java.util.Dictionary.)

Invalidating the Session Invalidating a session means to remove the HttpSession object and its values from the system. A user’s session can be invalidated manually or, depending on where the servlet is running, automatically. Some web servers automatically invalidate a session when there has been no page request for some period of time. To manually invalidate a session, use the session’s invalidate() method.

Let us now write a program that illustrates session tracking. This program keeps track of the number of times a web page has been visited.

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;public class counter10 extends HttpServlet{public void service (HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException


Page 24: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

{res.setContentType ("text/html");PrintWriter pw = res.getWriter();HttpSession hs = req.getSession(true);if (hs.getAttribute ("counter")==null){ hs.setAttribute("counter", new Integer (1));} else{ int count= ((Integer) hs.getAttribute ("counter")) .intValue()+1 hs.setAttribute ("counter", new Integer(count));}

pw.println ("<h1>you have visited the page"+hs.getAttribute ("counter") +

" no of times</h1>"); }


The HTML for the above program is as follows:

<body><form method = get action =”testAlias”><input type=submit></form></body>

After you deploy and run the servlet in a Web browser, you will get the output as given in Figure 3.1.

Fig. 3.1Output of Session Tracking Example

3.3 Cookies

Till now we have seen how to track session using the Servlet API, but we still have not discussed how a unique session id is maintained between a client and the server. This can be done using cookies. A cookie is a piece of data that can be embedded in HTTP request or response. The server embeds a cookie value in a response header and the browser returns this cookie value with each request.

A cookie can store information like the session ID to bind a particular HTTP request to a session. It can contain properties like comment, version number, and


Page 25: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

maximum lifetime. A server can provide one or more cookies to a client. Client software, such as a web browser, is expected to support twenty cookies per host, of at least four kilobytes each. Cookies that a client stores for a server are returned by the client to that sever and only that server.

To write a Cookie, the following steps are taken:

To send a cookie To send a cookie, you need to

1. instantiate the Cookie object2. set its attributes3. send the cookie.

To get information from a cookie To do this, you need to:

1. retrieve all cookies from the user’s request2. find the cookie or cookies with the name that you are interested in, using

standard programming techniques3. get the values of the cookies that you found.

Let us discuss each of these steps in detail:

Instantiate the Cookie object

The javax.servlet.http.cookie is used to create a cookie object. The constructor of this class takes two parameters, one for the name and the other for the value. this creates a cookie with the initial name and value. You can change the value inside the cookie later in the program by using the setValue() method.

The name of the cookie must be an HTTP/1.1 token. Tokens are strings that contain none of the special characters. (Alphanumeric strings qualify as tokens.) In addition, names that start with the dollar-sign character (“$”) are reserved and cannot be used. The value of the cookie can be any string, though null values are not guaranteed to work the same way on all browsers.

Set Attributes of the Cookie

There are various methods that can be used to set various cookie values and attributes. Table 3.1 lists some such methods.Method DescriptionsetComment(String) If a user agent (web browser) presents

this cookie to a user, the cookie’s purpose will be described using this comment.

setDomain(String) This cookie should be presented only to hosts satisfying his domain name pattern.

setMaxAge(int) Sets the maximum age of the cookie.setPath(String) This cookie should be presented only

with requests beginning with this URL.setSecure(boolean0 Indicates to the user agent that the

cookie should only be sent using a secure protocol (https).

setValue(String) Sets the value of the cookie should only be sent using a secure protocol (https).

setVersion(int) Sets the version of the cookie protocol used when this cookie saves itself.


Page 26: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Table 3.1Methods to set cookie values and attributes.

Sending Cookies

Cookies are sent as headers of the response to the client; they are added with the addCookie method of the HttpServletResponse class. If you are using a Writer to return text data to the client, you must call the addCookie() method before calling the HttpServletResponse’s getWriter method.

Retrieving the Cookies

Clients return cookies as fields added to HTTP request headers. To retrieve any cookie, you must retrieve all the cookies using the getCookies() method of the HttpServletRequest class.

The getCookies() method returns an array of Cookie objects, which you can search to find the cookie or cookies that you want. Since multiple cookies can have the same name, name of a particular cookie can be obtained by using the getName() method.

Getting the value of a cookie

Values of a cookie can be obtained by using the getValue() method.

Let us now write a program that adds three cookies and sets their maximum age using the setMaxAge() method (refer Table 3.1) and displays a message on the Web browser.

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class cookie1 extends HttpServlet {

public void service (HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException

{res.setContentType ("text/html");PrintWriter p = res.getWriter ();Cookie c = new Cookie ("EmpNo", "8000");Cookie c1 = new Cookie ("Emp_Name", "Ganesh");Cookie c2 = new Cookie ("User-id", "Ganesh_in");c.setMaxAge (10000);c1.setMaxAge (10000);c2.setMaxAge (10000);res.addCookie (c);res.addCookie (c1);res.addCookie (c2);p.print ("<html><body>");p.print ("<body> Response sets 3 cookies</body><br>");p.print("<h1> Thank U </h1>");

} }

The HTML file is given below:


Page 27: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<body><form method = get action = “soma”><input type=”submit”></form></body>

Deploy this application on J2EE and run it in Web Browser. The following will be displayed in the Web Browser.

Fig. 3.2Output of the Cookie Program

The cookies are saved on your machine. You can have a look at the folder named cookies on your machine and open the file with the name you specified for the context root (while deploying). The file is given in Figure 7.26. As you can see from the Figure 7.26, three cookies have been added. You can retrieve the cookies using the getCookies () method as discussed earlier.


Page 28: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Chapter: 4


Topics Discussed

Servlet Collaboration Servlet Chaining Request Dispatching

4.1 Servlet Collaboration

In the default servlet model, a servlet receives an HTTP request, executes some application logic, and prepares the response. This completes one request-response trip for the client. However, there are several scenarios in which this basic model is not adequate:

Several receive an HTTP request from a client, processes application logic, and a JavaServer Page drives the response. In this case the servlet is not responsible for response generation. Instead, the JSP page is responsible for dynamic content.

A servlet receives an HTTP request from a client, and processes application logic partially, and then hands over the request to another servlet. The second servlet completes the application logic, and either prepares the response, or requests a JSP page to drive the response.

In both the scenarios, the servlets is not completely responsible for processing a request. Instead, it delegates the processing to another servlet (or a JSP page, which is equivalent to a servlet at run-time).

There are two types of solutions for addressing the above requirements:

Servlet chaining: This was once a very widely used approach, and supported by some of the servlet engine vendors. Although this is not supported by the Java Servlet API specification, for the sake of completeness, you’ll find a short description below.

Request Dispatching: Request dispatching allows one servlet to dispatch the request to another resource (a servlet, a JSP page, or any other resource). Prior to version 2.2 of the servlet API, this approach used to be called `inter-servlet communication’. The API for supporting inter-servlet communication has now been deprecated, and has been replaced by request dispatchers.


Page 29: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

4.2 Servlet Chaining

Servlet chaining predates J2EE, and its component model. The idea of servlet chaining is very simple: you design a set of servlets, each of which does a single task. After developing these servlets, you configure your servlet engine to specify a chain of servlets for a given URL path alias. Once the servlet engine receives a request for this alias, the servlet engine invokes the servlets in the specified order. This is similar to piping on Unix, where output of one program becomes input for another program in the pipe.

Suppose you’ve servlets A, B, and C executing three parts of a request-response process for a single customer service. Let’s assume that / custService is the alias given to this chain (/custService=A, B, C). Consider a browser sending a request to the URL path pointing to this alias. The servlet engine sends all requests for this alias to servlet A. After executing sever A’s service method, the servlet engine invokes servlet B’s service method, followed by C’s service method. The final response is then sent to the client. Briefly, this is servlet chaining. Refer to the figure below for an overview of this approach:

The key feature of servlet chaining is that you configure the servlet engine to do the chaining. During setup, you specify the order in which these servlets should be invoked.

Servlet chaining was initially introduced in the Java Web Server, but was never part of the servlet APT specification. You’ll still find some books talking about servlet chaining, but be advised that this non-standard feature is not supported by most of the Web containers today. Instead, you should consider using the request dispatching approach.

4.2 Request Dispatching

Request dispatching allows a servlet or a JSP page to dispatch a request to another servlet, (or a JSP page, or even a plain HTML page), which will then be responsible for any further processing and for generating the response.



Servlet Engine

Alias Servlet A

Servlet B

Servlet C

Page 30: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

When the web container receives a request, it constructs request and response objects and invokes one of the servlet’s service methods with the request and response objects. This is a process of the web container dispatching a request to a servlet. What if this servlet wants to dispatch the same request to another servlet after some preliminary processing? For this purpose, the first servlet should be able to obtain a reference to the second servlet. Using this reference, the first servlet can dispatch a request to the second servlet. In simple terms, this is request dispatching.

The Java Servlet API has a special interface called javax.servlet.RequestDispatcher for this purpose.

RequestDispatcher Interface

public Interface RequestDispatcher

This interface encapsulates a reference to another web resource at a specified path within the scope of the same servlet context. A javax.servlet.RequestDispatcher object can be used to dispatch requests to other servlets and JSP pages.

This interface has two methods, which allow you to delegate the request-response processing to another resource, after the calling servlet has finished any preliminary processing.

The forward() Method

public void forward(ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException

This method lets you forward the request to another servlet or a JSP page, or an HTML file on the server; this resource then takes over responsibility for producing the response.

The include() Method

public void include (ServletRequest request, ServletResponse response) throws ServletException, java.io.IOException

This method lets you include the content produced by another resource in the calling servlet’s response.

Obtaining a RequestDispatcher Object

There are three ways in which you can obtain a RequestDispatcher object for a resource:

javax.servlet.ServletContext methods get RequestDispatcher() and getNameDispatcher():

public RequestDispatcher getRequestDispatcher(String path)public RequestDispatcher getNameDispatcher(String name)

javax.servlet.ServletRequest method getRequestDispatcher():

public RequestDispatcher getRequestDispatcher(String path)

Although these methods serve the same purpose, the usage depends on what information is available to you.


Page 31: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The two getRequestDispatcher() methods accept an URL.path referring to the target resource. However, the getRequestDispatcher() method on javax.servlet.ServletContext requires the absolute path (that is, the path name should be begin with a/). For example, if you have a servlet /myWebApp/servlet1, and want to get the RequestDispatcher object for /myWebApp/servlet/servlet2, you should specify the complete path relative to the root context. Here the root context is /myWebApp, and the absolute path is /servlet/servlet2.

The same method on javax.servlet.ServletRequest accepts both absolute and relative paths. In the above example, you could now also servlet2 as the path.

A javax.servlet.ServletRequest is associated with a URL path, and the web container can use this to resolve relative paths into absolute paths.

The getNameDispatcher () method is a convenience method that accepts a name associated with the servlet. This is the same name that you specify the deployment descriptor in the<servlet-name> element.

Note that the target resource (except for static resources) should implement the same type of HTTP request that the original servlet receives.

Example program for demonstrating the Servlet chaining is given below.

The HTML file with two fields name and password will be is posted to the Dispatch Servlet. The code of the HTML file is as follow:

The HTML file

<html> <head><title>Login Form</title></head> </body> <form action="testAlias" method="POST"> <BR><BR>

Login <input type=text name=name></BR><BR>Password <input type=password name=pass><BR></BR><input type=submit value = Login><input type=”reset” value=Cancel></form>


The Dispatch Servlet will do the following or including according to the parameters we pass through the text box in the HTML page.

The Dispatch Servlet is as follows

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;public class Dispatch extends HttpServlet{

RequestDispatcher rd;public void service (HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException {

res.setContentType ("text/plain");PrintWriter p = res.getWriter ();


Page 32: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

String name=req.getParameter("name");String pass=req.getParameter("pass");if (name.equals("Smitha")==false){




}p.println("The password given is "+pass);



The ForwardServlet.java is the Servlet to which the control is forwarded if the condition not satisfied.

The ForwardServlet.java

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;public class ForwardServlet extends HttpServlet{

public void service (HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException {

res.setContentType ("text/plain");PrintWriter p = res.getWriter ();String name=req.getParameter("name");p.println("The username given is "+name);p.println("So it is forwarded to the Forward Servlet");


The IncludeServlet is the Servlet which is the one when included in between when the condition satisfied .In this servlet the name alone is extracted and printed and the pass word will be printed in the calling servlet only.

The IncludeServlet.java

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;public class IncludeServlet extends HttpServlet{

public void service (HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException {

res.setContentType ("text/plain");PrintWriter p = res.getWriter ();String name=req.getParameter("name");p.println("The username given got in the Include page is "+name);

p.println("Back to the called servlet"); }



Page 33: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The inputs and outputs can be verified from the following figures.

For the above input the Include servlet is invoked in between and the output will be as above.


Page 34: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

For the above input the control is forwarded to the ForwardServlet and the name is printed there in the ForwardServlet.


Page 35: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Chapter: 5


Topics Discussed

Introducing JSP The Nuts and Bolts JSP Directives

The page Directive The Include Directive The taglib Directive

Scripting Elements Declarations Scriplets Expressions Standard Actions

The goal of the JavaServer Pages (JSP) specification is to simplify the creation and management of dynamic web pages, by separating content and presentation. JSPs are basically files that combine standard HTML 9or XML) and new scripting tags. JSPs therefore look somewhat like HTML, but they get translated into Java services the first time they are invoked by a client. The resulting servlet is a combination of the HTML from the JSP file and embedded dynamic content specified by the new tags. (This is not to say that JSPs must contain HTML: a JSP page might be composed only of Java code, or of custom tags that refer to externally compiled classes.)

In this chapter we will look at:

5.1 Introducing JSP

JSP is not a product but, like other Java APIs, a specification provided by Sun Microsystems for vendors to implement; the JSP specification builds on the functionality provided by the servlet specification. So what differentiates JSPs from servlets?

Servlets are Java’s answer to CGIs. They execute on the server and intercept browser requests, acting as a sort of middle layer between clients and other applications. In doing so, servlets tend to mix the dynamic content into the static part to generate HTML.

JSPs, on the other hand, are more in line with the J2EE model of separating static and dynamic content – separating presentation and logic – in a web application. That I the prime objective:

Simplifying the dynamic presentation layer in a multi-tiered architecture.

Whereas services force you to mix the code with the static content. JSPs can use beans with a specified scope to separate the code out, or tag extensions, which are covered in Chapters 12 and 13.


Page 36: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Keep in mind, that even though JSPs contain special scripting tags, under the hood they are nothing but servlets.

A simple JSP might look like this:

<%@page import=”java.util.Date”%><html><body>The current time is <%=new Date(), toString() %></body></html>

5.2 The Nuts and Bolts

Let us jump head-on into writing JSPs, The structure of a JSP page is a cross between a servlet and an HTML page, with Java code enclosed between the constructs <% and %> and other XML-like tags interspersed.

JSP tags fall into three categories:

Directives: These affect the overall structure of the servlet that results from translation

Scripting elements: These let you insert Java code into the JSP page (and hence into the resulting servlet)

Actions: These are special tags available to affect the runtime behavior of the JSP

You can also write your own tags, as we shall see in Chapters 12 and 13.

Some general rules are applicable to JSP pages:

JSP tags are case-sensitive.

Directives and scripting elements have a syntax, which is not based on XML, but an alternative XML-based syntax is also available.

Tags based on XML syntax have either a start tag with optional attributes, an optional body, and a matching end tag; or they have an empty tag (possibly with attributes – see example below):

<somejsptag attributename=”attribute value”>body



<somejsptag attributename=”attribute value” /> Attribute values in tags always appear quoted; either single or double

quotes can be used. The special strings &apos; and &quot; can be used (just as in HTML) if quotes are a part of the attribute value itself.

Any whitespace within the body text of a document is not significant, but is preserved during translation into a servlet.

The character \ (backlash) can be used as an escape character in a tag (for example, to use %, the sequence \ % can be used).


Page 37: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

URLs used by JSPs follow servlet conventions, and a URL starting with a /, called a context-relative path, is interpreted with reference to the web application to which the JSP page belongs. (The ServletContext is available as an implicit object within JSP pages, as well will see later.)

If the URL does not start with a / it is interpreted relative to the current JSP.

5.3 JSP Directives

JSP directives serve as message sent to the JSP container from the JSP. They are used to set global values such as class declarations, methods to be implemented, output content type, etc., and do not produce any output to the client. Directives have scope for the entire JSP file; in other words, a directive affects the whole JSP file, but only that file. Directives start with <%@ and end with %>; the general syntax is:

<%@ directivename attribute=”value” attribute=”value” %>

There are three main directives that can be used in JSP:

The page directive The include directive The taglib directive

5.3.1 The page Directive

The page directive is used to define and manipulate a number of important page-dependent attributes that affect the whole JSP (the entire compiled class file), and communicates these attributes to the JSP container. A page can contain any number of page directives, in any order, anywhere in the JSP. They are all assimilated during translation and applied together to the page. however, there can be only one occurrence of any attribute/value pair defined by the page directives in a given JSP. (An exception is the import attribute: there can be multiple imports.)

The general syntax of the page directive is:

<%@ page ATTRIBUTES %>

where the valid attributes are name value pairs as described overleaf:

Attribute Description Default valuelanguage Defines the scripting language to be

used. For future use if JSP containers support multiple languages.


extends The value is a fully qualified class name of the superclass that the generated) must extend.This attribute should normally be avoided, and only used with extreme caution, because JSP engines usually provide specialized super-classes with a lot of functionality to be extended by the generated servlet classes. Use of the extends attribute restricts some of the decisions that a JSP container can make.

Omitted by default


Page 38: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

import Comma separated list of packages or classes, just like import statements in usual Java code.

Omitted by default

session Specifies whether the page participates in an HTTP session. When “true” the implicit object named session (which refers to the javax.servlet.http.HttpSession) is available and can be used to access the current/new session for the page.

If “false”, the page does not participate in a session and the implicit session object is unavailable.


buffer Specifies the buffering model for the output stream to the client.If the value is “none”, then no buffering occurs and all output is written directly through to the ServletResponse by a PrintWriter.

If a buffer size is specified (such as “24kb”) then output is buffered with a buffer size not less than that value.

Implementation dependent; at least 8kb

autoFlush If “true”, the output buffer to the client is flushed automatically when it is full.

If “false’, a runtime exception is raised to indicate buffer overflow.



Defines the level of thread safety implemented in the page.

If the value is “true” the JSP engine may send multiple client requests to the page at the same time.

If “false” then the JSP processor queues up client requests sent to the page for processing, and processes them one at a time, in the order they were received. This is the same as implementing the javax.servlet.SingleThreadModel interface in a servlet.


info Defines an informative string that can subsequently be obtained from the page’s implementation of the Servlet.getServletInfo() method.

Omitted by default

errorPage Defines a URL to another JSP page, which is invoked if an unchecked runtime exception is thrown. The page implementation catches the instance of the Throwable object and passes it to the error page processing. See the isErrorPage attribute below.

Omitted by default

isErrorPage Indicates if the current JSP page is intended to be another JSP page’s error page.

If “true”, then the implicit variable



Page 39: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

exception is available and refers to the instance of the java.lang.Throwable thrown at run-time by the JSP causing the error.

contentType Defines the character encoding for the JSP and the MIME type for the response of the JSP page.

This can have either the form “MIMETYPE” or “MIMETYPE; charset=CHARSET” with an optional whitespace after the’;”.

CHARSET, or character encoding, if specified, must be the OIANA value for a character encoding.

The default value for the MIMETYPE is text/html; the default value for the CHARSET is ISO-8859-1.

Unrecognized attributes result in fatal translation errors.


The following JSP, pageDirective.jsp, contains an attribute-rich page directive:

<%@ page language=”Java” import=”java.rmi.*, java.util.*”session=”true” buffer=”12kb’ autoFlush=”true”info=”my page directive jsp” errorPage=”error.jsp”isErrorpage=”false” isThreadSafe=”false”%>

<html> <head> <title>Page directive test page</title></head><body> <hl>Page directive test page</hl>

This is a JSP to test the page directive. </body> </html>

5.3.2 The Include Directive

The include directive instructs the container to include the content of the resource in the current JSP, by inserting it, inline, in the JSP in place of the directive. Of course the file specified should be accessible and available to the JSP container.

It is important to note that the content of the included file is parsed by the JSP and this happens only at translation time (when the JSP page is compiled into a servlet).

The include action is used to include resources at runtime, as we will see later.

Most JSP containers usually keep track of the included file and recompile the JSP if it changes (they may choose not to recompile). The server may, however, choose whatever mechanism it prefers to read the included file. The syntax of the include directive is:

<%@ include file=”Filename” %>

The only available attribute, file, specifies the filename of the file to include.


Page 40: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================


The included file can be either a static file (such as an HTML file) or another JSP.

The example below, includeDirective.jsp, requests the inclusion, during compilation, of a copyright file containing HTML legal disclaimers.

<html> <head> <title>Include directive test page 1</title> </head> <body> <h1>Include directive test page 1</h1> <%@ include file="included.html"%> </body> </html>

included.html contains the following:

<font color="red" size="12">This is the content from the included HTML page<font>

On placing both these files in the C:\ProJavaServer\Chapter8\JSPExamples directory and requesting http://localhost:8080 /JSPExamples/includeDirective.jsp, the resulting output is as follows:

The new example shows how a JSP can be included. Consider the file includeDirective2. jsp:

<html> <head> <title>Include directive test page 1</title> </head> <body> <h1>Include directive test page 1</h1> <%@ include file="included.html"%> </body> </html>


Page 41: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The included JSP included.jsp is:

<%@ page import=”java.util.Date” %>Current date is <%= new Date() %>

Again, save both these files to the C:\ProJavaServer\Chapter8\JSPExamples directory. The result on requesting http://localhost:800/JSPExamples/includeDirective2.jsp is:

When includedirective2.jsp is translated, the relevant portion of the resulting servlet code, striped of comments, looks like this:

out.write(“<html>\r\n <head.\r\n <title>Include directive test page 2</title>\r\n </head>\r\n <body>\r\n <h1>Include directive test page 2</h1>\r\n\r\n “);

out.write(‘\r\n”);out.print (“Current date is “ );out.print (“ + new Date());out.write (“\r\n);out.write (“\r\n </body<\r\n</html>\r\n”);

You can see that the code from the included file has been inlined into the translated servlet.

5.3.3 The taglib Directive

The taglib directive allows the page to use tag extensions (customs tags) – see Chapters 12 and 13. It names the tag library that contains compiled Java code defining the tags to be used. The engine uses this tag library to find out what to do when it comes across the custom tags in the JSP. The syntax of the taglib directive is:

<%@ taglib uri=”tagLibraryURI” prefix=”tagPrefix” %>

and the available attributes are:

Attribut Description Default value


Page 42: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

euri A URI (Uniform Resource Identifier) that

identified the tag library descriptor. A tag library descriptor is used to uniquely name the set of custom tags and tells the container what to do with the specified tags.

Not specifying a value causes a compilation error

tagPrefix Defines the prefix string in prefix:tagname that is used to define the custom tag.

The prefixes jsp, jspx, java, javax, servlet, sun, and sunw are reserved.

For example if this value is mytag then when the container comes across any element that starts like <mytag:tagname … /> in the JSP, it references the tag library descriptor specified in the URI.

Not specifying a value causes a compilation error.

Tag libraries are a very powerful, and often misunderstood, concept, and will be covered in detail in coming Chapters.

5.4 Scripting Elements

JSP scripting elements allow java code – variable or method declarations, scriptlets (arbitrary Java code), and expressions – to be inserted into your JSP page.

5.4.1 Declarations

A declaration is a block of Java code in a JSP that is used to define class-wide variables and methods in the generated servlet. Declarations are initialized when the JSP page is initialized, and have `class’ scope in the generated servlet, so that anything defined in a declaration is available throughout the JSP to other declaration, expressions, and code. A declaration block is enclosed between <% ! and %> and does not write anything to the output stream. The syntax is:

<%! Java variable and method declaration(s) %>


Consider the simple JSP below, declaration.jsp:

<%! int numTimes = 3;

public String sayHello(String name) { return "Hello, " + name + " ! " ; }%>

<html> <head> <title>Declaration test page </title> </head><body> <h1>Declaration test page</h1>


Page 43: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<p>The value of numTimes is <%= numTimes %>.</p> <p>Saying hello to reader: " <%= sayHello("reader") %>". </p></body>


This declares an int variable called numTimes, and a sayHello () method that greets the requested person. Further down the page, expression elements (to be shortly) are used to return the value of numTimes to the browser and to invoke the sayHello () method.

When declaration.jsp is saved to the C:\ProJavaServer\Chapte8\JSPExamples directory and http: // localhost; 8080/JSPExamples/declaration. jsp is requested, the output is as follows:

The generated servlet contains the declarations code:

import javax.servlet.*;// … more import statements

public class 0002fdeclaration0002ejspdeclaration_jsp_1 extends HttpJspBase (

int numTimes = 3;

public String sayHello (String name) ( return “Hello, “ + name + “ !” ; }

// More generated code.

5.4.2 Scriptlets

A scriptlet is a book of Java code that is executed during the request-processing time, and is enclosed between <% and %> tags. What the scriptlet actually does depends on the code itself, and can include producing output for the client. Multiple scriptlets are combined in the generated servlet class in the order they appearing the JSP. Scriptlets, like any other Java code block or method, can modify objects inside them as a result of method invocations.

In Tomcat, all the code appearing between the <% and %> tags in the JSP gets put into the services() method of the servlet, as is, in the order in which it appeared. It is therefore processed for every request that the servlet receives. The syntax for scriplets is:

<% Valid Java code statements %>


Page 44: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================


In scriplet.jsp below, a scriptlet executes a loop 10 times, printing out a message each time to the browser window (using the implicit object out) and to the System.out stream (in other words, to the console window within which Tomcat is running).

<html> <head> <title>Scriptlet test page</title> </head> <body>

<h1>Scriptlet test page</h1>

<% for(int i=0;i< 10; i++) {

out.println ("<b>Hello World. This is a scriptlet test " + i +"</b><br>");System.out.println ("This goes to the System.out stream " + i);

} %></body>


Save scriplet.jsp to the C:\ProJavaServer\Chapter1\JSPEampales\directory and request http://localhost:8080/JSPExamples/scriptlet.jsp. The output to the browser window should be:

5.4.3 Expressions

An expression is a shorthand notation for a scriptlet that sends the value of a Java expression back to the client. The expression is evaluated at HTTP request processing time, and the result is converted to a String and displayed.


Page 45: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

An expression is enclosed in the <%=and%> tags. If the result of the expression is an object, the conversion is done by using the object’s toString() method. The syntax is:

<%= Java expression to be evaluated %>


Consider the example JSP overleaf (expression.jsp – again, save it inC:\ProJavaServer\Chapter8|JSPExamples), which sets up a simple counter and shows declarations, scriptlets, and expressions working together:

<html> <head> <title>Expression test page</title> </head> <body> <h1>Expression test page</h1> <%! int i=0 ; %> <% i++; %> Hello World! <%= "This JSP has been accessed " + i + " times" %></body></html>

An int variable is declared, and initially has the value 0. Each time this instance of the generated servlet is called (when the browser requests http://localhost:8080\JSPEamples\expression. jsp) the variable is incremented by the scriptlet. Finally, an expression is used to printout the value of I, together with some surrounding text.

After this JSP has been requested a number of times, the browser will display.

5.5 Standard Actions

Standard actions are tags that affect the runtime behavior of the JSP and the response sent back to the client. They have to be provided by all containers, irrespective of the implementation.

Effectively, a standard action is a tag that can be embedded in a JSP page. During compilation into a servlet, the container comes across this tag and replaces it with Java code the corresponds to the required predefined task.


Page 46: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

For example when it comes across the standard include action.

<jsp:include page=”myjsp.jsp” flush=”true” />

it takes the JSP myjsp. jsp, compiles it (if necessary), and includes the output produced by myjsp.jsp in the response, in place of the action tag. We will examine the semantics of this action in detail in a while.

The standard actions serve to provide page authors with basic functionality to exploit for common tasks. The standard action types are:








5.5.1 jsp:useBean

To separate code from presentation, it would be a good idea to encapsulate the code in a Java object (a JavaBean), and then instantiate and use this object within our JSP. The <jsp:useBean>, <jsp:setProperty>, and <jsp:getProperty> tags assist with this task.

The <jsp:useBean> action is used to instantiate a JavaBean, or locates an existing bean instance, and assigns it to a variable name (or id). We can also specify the lifetime of the object by giving it a specific scope (we cover this later in detail). </jsp:useBean> ensures that the object is available, with the specified id, in the appropriate scope as specified in the tag. The object can be referenced using as associated id from within the JSP, or even from other JSPs, depending on the scope.

The syntax for the <jsp:useBean> action is:

<jsp:useBean id=”name” scope=”scopeName” beandetails />

where and beandetails is one of:


class=”className” type=”typeName”

beanName=”beanName” type=”typeName”


The attributes available are:

Attribute Description Default


Page 47: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

valuesid The case sensitive name used to identify the

object instance.No default value

scope The scope within which the reference is available. Possible values are “page”, “request”, “session”, and ‘application”. These values will be explained shortly.


class The fully qualified class name. No default value

beanName The name of a bean, as you would supply to the instantiate() method in the java.beans.Beans class. This attribute can also be a request time expression.

It is permissible to supply a type and a beanName, and omit the class attribute.

The beanName follows the standard bean specification and can be of the form “a.b.c.’, where “a.b.c.” is either a class, or the name of a serialized resource in which case it is resolved as ‘a/b/c.er”. 9See the javaBeans specification for more details.)s

No default value

type This optional attribute specifies the type of the scripting variable to be created, and follows standard java casting rules. The type implemented by it, or the bean’s class itself.

Just like any casing operation, if the object is not of this type then java.lang.ClassCastException can be thrown at request time.

The value of the class attribute

Let us examine the underlying semantics that occur because of this tag in the order they occur:

The container tries to locate an object that has this id, in the specified scope.

If the object is found, and a type has been specified in the tag, the container tries to cast the found object to the specified type. A ClassCastException is thrown if the cast fails.

If the object is not found in the specified scope, and no class or beanName is specified in the tag, an InstantiationException is thrown.

If the object is not found in the specified scope, and the class can be instantiated, then this is done, and a reference to the object is associated with the given id, in the specified scope. If this fails then an InstantiationException is thrown.

If the object is not found in the specified scope and a beanName is specified, then the instantiate(1) method of java.beans.Beans is invoked, with the beanname as an argument. If this method succeeds, the new object reference is associated with the given id, in the specified scope.

If a new bean instance has been instantiated and the <jsp:useBean> element has a non-empty body, the body is processed; during this processing the new variable is initialized and available. Scriptlets or the


Page 48: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<jsp:setProperty> standard action can be used to initialize the ban instance, if necessary.

The meanings of the possible values of the scope attribute will be covered in more detail shortly, but in brief:

Page scope means that the object is associated with this particular request to this page.

request scope means that the object is associated it this particular client request. If the request is forwarded to another JSP using the <jsp:forward> action, or if another JSP is included using the <jsp:include> action, the object will available.

session scope means that the object will be available during any requests made by the name client within the current session.

application scope means that the object will be available in any JSP page with the same web application.

The container looks for the Java class you specified in the CLASSPATH for that web application. If you are creating a bean of a class you have written yourself, place the compiled .class file either under the WEB-INF\classes directory in your web application, or in a JAR file in the WEB-INF\lib directory.

We will see an example of the <jsp:useBean>action once we have looked at <jsp:setProperty> and <jsp:getProperty>.

5.5.2 jsp:setProperty

The <jsp:setProperty> standard tag is used in conjunction with the <jsp:useBean> action described in the proceeding section, to set the value of bean properties. Bean properties can be either simple or indexed.

The properties in a bean can be set either:

At request time from parameters in the request object

At request time from an evaluated expression

From a specified string (or hard coded in the page)

When setting bean properties from the request object, the JSP can choose to set all properties in the bean via the standard action:

<jsp:setProperty name=”help” property=***/>

or a single property can be set explicitly by an action such as;

<jsp:setProperty name=”help” property=”word” />

The <jsp:setProperty> action uses bean introspection to discover what properties are present, their names, whether they are simple or indexed, their type, and their accessor and mutator methods.


Page 49: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The syntax of the <jsp:setProperty> action is:

<jsp:setProperty name=”beanName” propertydetails />

when propertydetails is one of:



property=”propertyName” param=”parameterName”

property=”propertyName” value=”propertyValue”

and propertyValue is a string or a scriptlet. The attributes are:



name The name of a bean instance, which must already have been defined by a <jsp:useBean> tag.Note that the name is <jsp.setProperty> and the one for <jsp:useBean> must be the same.

property The name of the bean property whose value is being set.

If the property attribute has the value “ * “, the tag looks through all the parameters in the request object and tries to match the request parameter names and types to property names and types in the bean. The values in the request are assigned to each matching bean property, unless a request parameter has the value “”, in which case the bean property is left unaltered.

param When setting bean properties from request parameters, it is not necessary for the bean have the same property names as the request parameters.

This attribute is used to specify the name of the request parameter whose value you want to assign to a bean property. If the param value is not specified, it is assumed that the request parameter and the bean property have the same name.

If there is no request parameter with this name, or if it has the value “ “, the action has no effect on the bean.

value The value to assign to the bean property. This can be a request-time attribute, or it can accept an expression as its value.

(A tag cannot have both param and value attributes.)

When properties are assigned from String constants or request parameter values, conversion is applied using the standard Java conversion methods; for example, if a bean property is of type double or Double the java.lang.Double.valueOf (String) method is used. However, request-time expressions can be assigned to properties of any type, and the container performs no conversion. For indexed properties, the value must be an array.


Page 50: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

5.5.3 jsp:getProperty

The <jsp:getProperty> action is complementary to the <jsp:setProperty> action, and is used to access the properties of a bean. It accesses the value of a property, converts it to a String, and prints to the output stream to the client.

To convert the property to a String, the action:

Invokes the toString () method on the property, if it is an object.

Converts the value directly to a String, if it is a primitive, using the valueOf() method of the corresponding wrapper class for the primitive type

This is just like the behavior of Java’s System.out.println() method.

The syntax is:

<jsp:getProperty name=”name” property=”propertyName” />

and the available attributes are:

Attribute Descriptionname The name of the bean instance from which the property is obtained.property Names the property to get; this is the instance variable in the bean.

Of course, you must create a bean before using <jsp:getProperty>, by using <jsp:useBean> or by instantiating the object by a new operator.

Having seen the <jsp:useBean>, <jsp:setProperty>, and<jsp:getProperty> actions, let’s build a simple example using all three. Our example will ask the user for their name and their favorite programming language, and then issue a verdict on their choice. The HTML form page, beans.html, is very simple:

<html> <head> <title>useBean action test page</title> </head> <body> <h1>useBean action test page</h1> <form method="post" action="beans1.jsp"> <p>Please enter your username; <input type="text" name="name"> <br>What is your favorite programming language?

<select name="language"><option value="Java">Java<option value="C++">C++<option value="Perl">Perl

</select> </p>

<p><input type="submit" value="Submit information"></form>

</body> </html>

This sends a POST request to beans.jsp two parameters: name and language.beans1.jsp is also quite simple.

<jsp:useBean id="languageBean" scope="page" class="bean1.LanguageBean">


Page 51: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<jsp:setProperty name="languageBean" property="*" />


<head><title>useBean action test result</title>

</head><p>Hello, <jsp:getProperty name="languageBean"

property="name"/>.</p> <p>Your favorite language is <jsp:getProperty name="languageBean" property="language" />. </body></html>

All the Java code has been removed to the LanguageBean class. beans .jsp creates an instance of LanguageBean with page scope, and uses the property-=”*” form of the <jsp:setProperty> action to set the bean’s name and language properties. It can then use the <jsp:getProperty> action to retrieve the values of these properties, and also the languageComments property.

Finally, the source of LanguageBean is as follows:

package bean1;public class LanguageBean{

private String name;private String language;private String languageComments;

public LanguageBean(){}

public void setName (String name){

this.name = name;}

public String getName(){

return name;}

public void setLanguage (String language){

this.language = language;}

public String getLanguage(){

return language;}


This is a nice, simple class with a no-argument constructor, set and get methods for the name and language properties, and also a getLanguageComments () method. This last method uses the value of the language property to issue some comments on the user’s chosen language – this is invoked by the <jsp:getProperty name=”languageBean” property=”languageComments”/> action in beans.jsp.


Page 52: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Save beans.jsp and beans .jsp to C:\ProJavaServer\Chapter8\JSPExamples, and languageBean.java to C:\ProJavaServer\Chapter8\JSPExamples\src. Compile the bean into C:\ProJavaServer\Chapte8\JSPExamples\WEB-INF\classes (create this directory first) by running the command:

javac -d ..\WEB-INF\classes LanguageBean.java

from the src directory. Then point your browser athttp: // localhost: 8080/JSPExamples/beans.html:

Enter your name and choose your favored language, then click the Submit information button:

The advantage of this approach over that used in previous examples (in which we freely mixed Java code and HTML) should be clear. Removing the logic to the languageBean class has made our JSP page much more readable, and more easily edited by someone who is a skilled web designer but does not understand the details of Java programming.

5.5.4 jsp:param


Page 53: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The <jsp:param> action is used to provide other tags with additional information in the form of name-value pairs. It is used in conjunction with the <jsp:include>.,<jsp:forward>, and <jsp:plugin> action, and its use is described in the relevant sections that follow. The syntax is:

<jsp:param name=”paramname” value=”paramvalue” />

and the available attributes are:



name The key associated with the attribute. (Attributes are key-value pairs.value The value of the attribute.

5.5.5 jsp:include

This action allows a static or dynamic resource, specified by a URL, to be included in the current JSP at request processing time. An included page has access to only the JspWriter object, and it cannot set headers or cookies. A request-time exception will be thrown if this is attempted. This constraint is equivalent to that imposed on javax.servlet.RequestDispatcher’s include () method, which is what servlets use if they want to do this type of inclusion.

If the page output is buffered then the buffer is flushed prior to the inclusion. The include action pays a small penalty in efficiency, and precludes the included page from containing general JSP code.

The syntax of the <jsp:include> action is:

<jsp:include page=”URL” flush=”true” />


<jsp:include page=“URL” flush=“true”> <jsp:param name=“paramname” value=“paramvalue” />


the attributes of the <jsp:include> action are:

Attribute Descriptionfilename The resource to include. The URL format is the same is described

earlier for the include directive.flush In JSP 1.1 this value must always be “true”, and “false” is not

supported. If the value is “true”, the buffer in the output stream is flushed before the inclusion is performed.

A <jsp:include> action may have one or more <jsp:param> tags in its body, providing additional name-value pairs. The included page can access the original request object, which will contain both the original parameters, and the new parameters specified using the <jsp:param> tag. If the parameter names are the same, the old values are kept intact, but the new values take precedence over the existing values.

For example, if the request has a parameter paraml=myvalue1, and a parameter param1-myvalue2 is specified in the <jsp:param> tag, the request received on the second JAP will have param=myvalue2, myvalue1. The augmented attributes can be extracted from the request using the getParameter (String paramname) method in the javax.servlet.ServletRequest interface.


Page 54: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

It is important to understand the difference between the include directive and this include action; the difference is summarized in the table below:

Include type

Syntax Done when Included content


directive <%@ include file=”filename” %>

Compilation time

Static Parsed by container

action <jsp:include page=” filename” />

Request processing time

Static or Dynamic

Not parsed but included in place

The include directive lets you include resources into multiple pages but requires you to update the modification date on the pages doing the include if the resource changes (in other words the container has to translate them again to reflect the changes). The include action includes files at request-processing time.

Use the include directive if your resource is not going to change frequently.Use the include action when the resource is frequently changing or is dynamic.

Let’s look at an example. The JSP below, includeAction.jsp, shows both the include types, for both a static and a dynamic resource:

<html> <head> <title>Include Action test page</title> </head> <body>

<h1>Include Action test page</h1>

<h2>Using the include directives</h2>

<%@ include file="include2.html" %> <%@ include file="include2.jsp" %>

<h2>Using the include action</h2>

<jsp:include page="include2.html" flush="true" /> <jsp:include page= "include2.jsp" flush="true" />

</body> </html>

The two included files are include2.html:

<p>This is some static text in the html file</p>

and include2.jsp:

<%@ page import="java.util.Date" %><%= "Current date is " + new Date() %>

Saving these files in C;\PreoJavaServer\Chapter8\JSPExamples and requesting http://locahost:8080/JSPExamples/includeAction.jsp, we get:


Page 55: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Even though the output from the two types of includes may look identical, there is a subtle difference. Let us look at an excerpt from the generated servlet class, tidied up a little.

// …

public void _jspService (HttpServletRequest request, HttpServletResponse response)

throws IOException, ServletException { // …

out.write (“<html>\r\n <head.\r\n <title>Include Action test page</title>\r\n <head>\r\n <body>\r\n <h1>Include Action test page</h1>\r\n\r\n <h2>Using the include directives</h2>\r\n\r\n “);

out.write (“<h3>This is some static text in the html file</h3>”); out.write (“\r\n “); out.write (“r\n”); out.print ( “Current date is “ + new Date() ); out.write (“\r\n\r\n <h2>Using the include action</h2>\r\n\r\n “); { String _jspxqStr = “ “; out.flush(); pageContext.include (“include2.html” + _jspx_qStr); } out.write (“\r\n “); { String _jsqpx_qStr = “ “; out.flush() ; pageContext.include (“include2.html” + _jspx_qStr); } out.write (“\r\n\r\n </body>\r\n<html>\r\n);

//… }

The highlighted lines in the above code show how the container in-lines the resources for the include directive, and invokes them dynamically for the include action. To reiterate the difference, see what happens when the included resources are changed (without changing the parent JSP that includes them). Change include2.html so that it contains:

<p>This is some new text in the html file</p>

and change icnlude2.jsp so that its contents are now:


Page 56: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<p>This is the new JSP</p>

When the page is requested again, the output now looks like this

The parts included using the include directive are not altered, because the parent JSP (includeAction.jsp) has not changed and hence is not recompiled; however, the parts included using the include action are changed, because the include action performs the inclusion afresh each time the parent JSP is requested.

5.5. 6 jsp: forward

The <jsp:forward> action allows the request to be forwarded to another JSP, to a servlet, or to a static resource. This is particularly useful when you want to separate the application into different views, depending on the intercepted request. We saw this design approach with servlets in Chapter 9, and will see more of it later in this chapter. The syntax is:

<jsp:forward page=“URL” /><jsp:forward page=“URL”> <jsp:param name=”paramname” value=paramvalue” /> …</jsp:forward>

The resource to which the request is being forwarded must be in the same context as the JSP dispatching the request. Execution in the current JSP stops when it encounters a <jsp:forward> tag, the buffer is cleared, and the request is modified (this is a server-side redirect and the response buffer is cleared when it is processed) to assimilate any additionally specified parameters in the same way as described for the <jsp:include> action.

If the output stream was not buffered, and some output has been written to it, a <jsp:forward> action will throw a java.lang.IllegalStateException. The behavior of this action is exactly the same as the forward () method of the javax.servlet.RequestDispatcher.

Let’s see a simple example of the <jsp:forward> action in use – a simple login form. The login form itself, in forward.html, is straightforward, sending a POST request to forward.jsp:



Page 57: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<head> <title>Forward action test page</title> </head> <body> <h1>Forward action test page</h1>

<form method="post" action="forward.jsp"> <p>Please enter your username: <input type="text" name="username"> <br>and password: <input type="password" name="password"> </p>

<p><input type="submit" value="Log in"> </form>



forward .jsp is the first JSP page we have seen that contains no HTML code:

<%if ((request.getParameter ("username").equals ("Richard")) &&(request.getParameter ("password").equals ("xyzzy"))) {%>

<jsp:forward page="forward2.jsp" />

<% } else { %>

<%@ include file="forward.html" %>

<% } %>

The checks whether the username and password are acceptable to the system, and if so forwards the request to forward2.jsp; if the login attempt fails, it uses the include directive to present the login form to the user again.

In a real-world example the password-checking code would check against a database or a JNDL server, the Java code would be removed to a JavaBean or a tag extension, and the whole application would probably be secured using HTIPS.

Finally, forward2.jsp presents the successfully logged-in user with a welcome page. Since the original request, including the form parameters, has been forwarded to this JSP, we can use the request object to display the user’s name:

<html> <head> <title>Forward action test: Login successful!</title> </head><body> <h1>Forward action test: login successful</h1> <p>Welcome, <%= request.getParameter("username") %></body></html>


Page 58: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Save all these files in C:\ProJavaServer\Chapter8|JSPExamp[les and request http://localhost:8080/JSPExamples/forward.html:

Entering the username Richard and the password xyzzy, we get to this page:

If any other username or password is entered, the login form is displayed again.

5.5.7 jsp:plugin

The <jsp:plugin> action is used in pages to generate client browser specific HTML tags (<OBJECT> or <EMBED>) that result in the download of the Java Plug-in software, if required, followed by the execution of the applet or JavaBeans component that is specified in the tag.The <jsp:plugin> tag can optionally have two additional support tags:


Page 59: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<jsp:param>, to pass additional parameters to the Applet or JavaBeans component.

<jsp:fallback>, to specify the content to the displayed in the client browser if the plugin cannot be started because the generated tags are not supported. The <jsp:fallback> tag does that the HTML ALT attribute and <NOFRAMES> tag do.

The available attributes for the <jsp:plugin> tag are:

Attribute Details Requiredtype Identifies the type of the component: a

Bean, or an AppletYes

code Same as HTML syntax Yescodebase Same as HTML syntax Noalign Same as HTML syntax Noarchive Same as HTML syntax Noheight Same as HTML syntax No, but some browsers

do not allow an object of zero height due to security issues

hspace Same as HTML syntax Nojreversion The Java runtime environment version

needed to execute this object

Default is “1.1”


name Same as HTML syntax Novspace Same as HTML syntax Notitle Same as HTML syntax Nowidth Same as HTML syntax No, but some browsers

do not allow an object of zero width due to security issues


URL where Java plugin can be downloaded for Netscape Navigator

Default is implementation defined


iepluginurl URL where Java plugin can be downloaded for Internet Explorer

Default is implementation defined


5.6 Implicit Objects

The Servlet API includes interfaces that provide convenient abstractions to the developer, such as HttpServletRequest, HttpServletResponse, HttpSession, etc. These abstractions encapsulate the object’s implementation; for example, the HttpServletRequest interface represents the HTTP data sent from the client along with headers, form parameters, etc., and provides convenient methods like getParameter(), and getHeader() that extract relevant data from the request.

JSP provides certain implicit objects, based on the servlet API. These objects are accessed using standard variables, and are automatically available for use in your JSP writing any extra code. The implicit objects available in a JSP page are:





Page 60: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================






The request Object

The request object represents the request that triggered the service() invocation. It is the HttpServletRequest that provides access to the incoming HTTP headers (for example, for cookies), request type (GET/POST), and request parameters, among other things. Strictly speaking, the object itself will be a protocol and implementations-specific subclass of javax.servlet.ServletRequest, but few of any), JSP containers currently support non-HTTP servlets. It has request scope.

The response Object

The response object is the HttpServletResponse instance that represents the server’s response to the request. It is legal to set HTTP status codes and headers in the JSP page once output has been sent to the client (even though it is not permitted in servlets, since the output stream is buffered). Again, the object itself will, strictly speaking, be a protocol- and implementation-specific subclass of javax.servlet.ServletResponse. It has page scope.

The pageContext Object

The pageContext object provides a single point of access to many of the page attribute and is a convenient place to put shared data within the page. It is of type javax.servlet.jsp.PageContext, and has page scope.

The session Object

The session object represents the session created for the requesting client. Sessions are created automatically, and this variable is available even when there is no in-coming session (unless, of course, you have used a session=”false” attribute in the page directive, in which case variable will not be available). It is of type javax.servlet.http.HttpSession, and has session scope.

The application Object

The application object represents the servlet context, obtained from the servlet configuration object. It is of type javax.servlet.ServletContext and has application scope.

The out Object

The out object is the object that writes into the output stream to the client. To make the response object useful, this is a buffered version of the java.io.PrintWriter class, and is of type javax.servlet.jsp.JspWriter. The buffer size can be adjusted via the buffer attribute of the page directive.


Page 61: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The config Object

The config object is the ServletConfig for this JSP page, and has page scope. It is of type javax.servlet.ServletConfig.

The page Object

The page object is the instance of the page’s implementation servlet class that is processing the current request. It is of type java.lang.Object, and has page scope. The page object can be thought of as a synonym to this within the page.

5.7 Scope

The scope of JSP objects – JavaBeans and implicit objects – is critical, as it defines the how long, and from which JSPs, the object will be available. For example, the session object has a scope, which exceeds that of a page, as it may span several client requests and pages. The application object can provide services to a group of JSP pages that together represent a web application.

JSP scopes internally rely on contexts. A context provides an invisible container for resources, and an interface for them to communicate with the environment; for example, a servlet executes in a context (an instance of ServletContext, in fact). Everything that the servlet needs to know about its server can be extracted from this context, and everything the server wants to communicate to the servlet goes through the context. A rule of thumb:

Everything in JSP is associated with a context, and every context has a scope.

What happens when a bean tag is compiled for the different values of scope can be seen below:

Page Scope

An object with page scope is bound to the javax.servlet.jsp.PageContext.

This is relatively simple – It means that the object is placed in the PageContext object, for as long as this page is responding to the current request. An object with this scope can be accessed by invoking the getAttribute() methods on the implicit pageContext object.

The object reference is discarded upon completion of the current Servlet.service() (in other words, when the page is fully processed by the servlets generated from the JSP). When generating the servlet, the servlet engine creates an object in the service() method which follows the usual object scope conversion in java. This object is created and destroyed for each client request to the page.

This is the default scope for objects used with the <jsp:useBean> action.

Request Scope

request scope means that the object is bound to the javax.servlet.ServletRequest, and can be accessed by invoking the getAttribute() methods on the implicit request object.

The object reference is available as long as the HttpRequest object exists, even if the request is forwarded to different pages, or if the <jsp:include> action is used. The underlying, generated servlet relies on binding the object to the HttpServletRequest using the setAttribute (String key, Object value) method in


Page 62: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

the HttpServletRequest; this is transparent to the JSP author. The object is distinct for every client request (in other words it is created afresh and destroyed for each new request).

Session Scope

An object with session scope is bound to the javax.servlet.jsp.PageContext, and can be accessed by invoking the getValue() methods on the implicit session object.

In earlier implementations of the servlet API, a session always ran under a separate session context. (Though deprecated for security reasons, an implementation for the HttpSessionContext interface is still available on most servers. It allows you to get a list of sessions or a particular session by its ID – and that’s not really that secure.) These days, the only session ID you can get at is the one that’s part of the request from the client, passed to the PageContext and made available to the JSP.

The generated servlet relies on binding the object to the HttpSession using the setAttribute (String key, Object value) method. This too is transparent to the JSP author. The object is distinct for every client, and is available as long as the client’s session is valid.

Application Scope

Application scope means that the object is bound to the javax.servlet.ServletContext. An object with this scope can be accessed by invoking the getAttribute.() methods on the implicit application object

This is the most persistent scope. The generated servlet relies on binding the object to the ServletContext using the setAttribute (String key, Object value) method in the ServletContext. This is not unique to individual clients and, consequently, all clients access the same object as they all access the same ServletContext.


Page 63: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Chapter: 6


Topics Discussed

Tag Extension 101 Anatomy of a Tag Extension Tag Handlers

The javax.servlet.Jsp.tagext.Tag Interface The javax.servlet.jsp.tagext.BodyTag Interface The javax.servlet.jsp.tagext.BodyContent Class Convenlence Classes The javax.servlet.jsp.tagext.TagExtraInfo Class Objects Available to Tag Handlers The Simple Example Revisited

Tag Library Descriptors Using Tag Extensions in JSP Pages Deploying the Packaging Tag Libraries

No Packaging WAR

From the point of view of the JSP developer, the only significant new feature of JSP 1.1 is support for tag extensions (often referred to as customs tags). However, this proves to be very significant indeed.

Tag extensions look like HTML, (or rather, XML) tags embedded in a JSP page. They have a special meaning to a JSP engine at translation time, and enable application functionality to be invoked without the need to write Java code in JSP scriptlets. Well-designed tag extension libraries can enable application functionality to be invoked without the appearance of programming.

So in this chapter, we’ll look at the basis of writing your own tags and then in the next chapter we’ll look at some more advanced examples. So in this chapter we will cover:

Tag extension basics

The anatomy of a tag extension

How do deploy a tag library

How to write custom tag extensions

Let’s get started then with what tag extensions are all about.

6.1 Tag Extension 101


Page 64: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Consider the <jsp:forward> action provided by the JSP specification. This tag dispatches the current request to another page in the current web application. It can be invoked with the following syntax:

<jsp:forward page=”next.jsp” />

We can also to add additional parameters to the request before forwarding with an extend usage of <jsp:forward>, which nests one or more <jsp:param> tags within the <jsp:forward> tag:

<jsp:forward page=”next.jsp” > <jsp:param name=”image” value=”house.gif” /></jsp:forward>

Tax extensions allow a vast range of new functionality to be added to the JSP language and they can be invoked in a similarly intuitive way. For example, I could create a tag named <wrox:forward>, specify what attributes and subtags, if any, it requires, and implement it to perform a custom action before forwarding. Not only can this be added simply into the web page, it enforces separation of code and presentation, decouples the call from the class that implements the functionality associated with the tag, and can be simply incorporated into a design tool.

The key concepts in tag extensions are:

Tag name:A JSP tag is uniquely identified by a combination of prefix (in this case jsp), and suffix (in this case forward), separated by a colon.

Attributes:Tags may have attributes, which use the XML syntax for attributes. The <jsp:forward> tag above has one attribute (page), while the <jsp:param> attribute has two (name and value). Attributes may be required or optional.

Nesting:Note how the <jsp:param> subtag is used in the second example above. Tag extensions can detect nested tags at runtime and cooperate. A tag directly enclosing another tag is called the parent of the tag it encloses: in the example above, the <jsp:forward> tag is the parent of the <jsp:param> tag.

Body content:This is anything between the start and end elements in a JSP tag, excluding subtags. A tag extension can access and manipulate its body content. Neither the <jsp:forward> not <jsp:param> tags require body content. We will see later an example of a tag that can reverse its body content. It will be invoked like this (the body content is shown in bold):

<examples:reverse>Able was I ere I saw Elba


The functionality associated with a tag is implemented by one or more Java classes. The tag handler (the class implementing the tag itself) is a JavaBean, with properties matching the tag’s XML attributes. A Tag Library Descriptor (TLD) file is an XML document that describes a tag library, which contains one or more tag extensions. The JSP taglib


Page 65: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

directive must be used to import the tag library in each JSP that wishes to use any of them.

Why, besides a clever syntax, might we choose to use tax extensions rather than JSP bean? Are tag extensions not simply another way of allowing JSP pages to parcel out work to Java classes?

Due to the richer interaction between the hosting JSP page and tax extensions, tag extensions can achieve directly what beans can only achieve in conjunction with scriptlets. Tag extensions may access the PageContext, write output to the output writer, redirect the response, and define scripting variables. As an indication of their power, all the standard JSP actions provided via tags of form <jsp:XXX> could be implemented using tag extensions. The behavior of tag handlers is configured by their XML attributes and their body content (which can be the result of evaluating JSP expressions at runtime).

Typical uses of tag extensions are:

To conceal the complexity of access to a data source or enterprise object from the page (possibly, the page author, who may not be experienced with enterprise data)

To introduce new scripting variables into the page

To filter or transform tag content, or even interpret it as another language

To handle iteration without the need for scriptlets

Tag extensions can be used to deliver a range of functionality limited only by developers’ imaginations and sensible programming practice.

Tax extensions differ from beans in that they are common building blocks, not tailored resources for a particular page or group of pages. Tags receive the attributes that control their behavior from the JSP pages using them, not the request to a particular JSP (as in the case of request bean property mappings) A well-designed tag extension may be used in many JSP pages.

This reusability is particularly important. Since their implementation and interaction with the JSP engine is well defined in the JSP 1.1 specification, libraries of tax extensions can be developed and distributed, on a commercial or open source basis. Generic tags can be developed for particular industries or application types.

Tag extensions, although new to JSP, are a very old concept in dynamic page generation. Products such as Apple’s WebObjects and BroadVision have delivered rich functionality through custom tags for years, although in a proprietary context. This experience in the use of custom tags can be valuable to JSP developers.

Tag extensions are a particularly welcome addition to the JSP developer’s armory because they are easy to implement. The API surrounding them is relatively simple, and it is possible to use them to achieve results quickly. This is a reflection of the elegance of the design if the tag extension mechanism; in the true Java spirit it delivers rich functionality without excessive complexity:

The examples and most of the discussion in this chapter and the next assume that tag extensions will be used to generate HTML markup. While this is currently their most likely use, tag extensions can be used to generate any content type supported by JSP:


Page 66: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

6.2 Anatomy of a Tag Extension

Before we return to our simple example, let’s cover some basic theory of tag extensions.

A number of components are required to implemented a tag extension. The minimal requirement is a tag handler and a tag library descriptor.

A tag handler is a Java bean implementing one of two interfaces defined in the javax.servlet.jsp.tagext package, Tag or BodyTag. These interfaces define the lifecycle events relevant to a tag; most importantly, the calls the class implementing the tag will receive when the JSP engine encounters the tag’s opening and closing tags.

A tag library descriptor, as we have seen, is an XML, document containing information about one or more tag extensions.

More complex tags will require an additional class extending the abstract class javax.servlet.jsp.tagext.TagExtraInfo to provide information about scripting variables that are made available to JSPs through the use of tags.

TagExtraInfo subclasses may also perform custom validation of tag attributes. Of course, the classes implementing a tag may require any number of helper classes, which will need to be packaged with the tag for it to be a complete deployable unit.

Before tags can be used in a JSP, the taglib directive must be used to import a tag library and associate the tags it contains with a prefix.

Let’s look at each of these requirements in turn.

6.3 Tag Handlers

When the JSP engine encounters a tag extension in a JSP at translation time, it parses the tag library descriptor to find the required tag handler class, and generates code to obtain, and interact with, the tag handler. The Tag or BodyTag interfaces, one of which must be implemented by any tag handler, define callbacks that the servlet resulting from the JSP engine’s code generation will make to the tag handler instance at runtime.

For performance reasons, JSP engines will not necessarily instantiate a new tag handler instance every time a tag is encountered in a JSP. Instead, they may maintain a pool of tag instances, reusing them where possible. When a tag is encountered in a JSP, the JSP engine will try to find a Tag instance that is not being used, initialize it, use it and release it (but not destroy it), making it available for further use. The programmer has no control over any pooling that may occur. The repeated use model is similar to a servlet lifestyle, but note one very important difference; tag handler implementations don’t need to concern themselves with threat safety. The JSP engine will not use an instance of a tag handler to handle a tag unless it is free. This is good news: as with JSP authoring in general, developers need to worry about threading issues less often than when developing sevlets.

6.3.1 The javax.servlet.Jsp.tagext.Tag Interface

The Tag interface defines a simple interaction between the JSP engine and the tag handler, sufficient for tags that don’t need to manipulate their body content. Its core methods are the calls implementing classes will receive when the JSP engine


Page 67: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

encounters the tag’s opening and closing tags, doStartTag() and doEndTag (). Before we look at the method contracts in more detail, a sequence diagram helps to visualize the calls made to the tag handler by the compiled servlet. Assume that the container already has a tag handler instance available, and in the default state:

Let’s look at the messages in more detail:

The container initializes the tag handler by setting the tag handler’s pageContext property, which the tag handler can use to access information available to the JSP currently using it.

The container sets the tag handler’s parent property. (Parent may be set to null, if the tag is not enclosed in another tag.)

Any tag attributes defined by the developer will be set. This is a mapping from the XML attributes of the tag to the corresponding properties of the tag handler bean. For example, in the case of a tag invoked like this <mytags:test name=”John” age=”43” />, the container will attempt to call the setName() and setAge() methods on the tag handler. The container will attempt to convert each attribute to the type of the corresponding bean property: for example, the String “43” will be converted to an int in this case. If the type conversion fails, an exception will be thrown and must be handled by the calling JSP page. (From a JSP’s point of view, there is no different between an exception thrown by a tag handler and one thrown by an expression of scriptlet in the page.)

Next, the container calls the tag handler’s doStartTag () method.

The container calls the doEndTag () method.

The container calls the release() method. This is not equivalent to a finalizer. Tag handlers differ from page beans in that their lifecycle is entirely independent of that of the JSPs that use them. Tag handlers must support repeated use before destruction, possibly in a number of JSPs. The implementation of the release() method must ensure that any state that may cause conflict in future uses it reset, and that any resources required during the tag’s execution are freed.

Lets look at the doStartTag() and doEndTag() methods:

int doStartTag() throws JspException

Called after the tag has been initialized, when the JSP engine encounters the opening of a tag at run time. Its return value should be one of two constants defined in the Tag interface: EVAL_BODY_INCLUDE, which instructs the JSP engine to evaluate both the tag’s body and any child tags it has, or SKIP_BODY, which instructs the JSP engine to ignore the body. This can throw a JspException, as will most of methods in the tag handler API when an error condition is encountered; how it will be handled will depend on the JSP page using the tag. Most JSP pages will use an error page, so an exception thrown in a tag will abort the rendering of the page.

int doEndTag () throws JspException

doEndTag () is called when the JSP engine encounters the closing tag of an element at run time. Its return value can be EVAL_PAGE or SKIP-PAGE. EVAL_PAGE will cause the JSP engine to evaluate the rest of the page, SKIP_PAGE to terminate evaluation of the page. The SKIP_PAGE return value should be used only with very


Page 68: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

good reason; using tag handlers to terminate page evaluation is even worse than sprinkling random return statements in Java code, and may be confusing to the reader. A legitimate use might be to terminate page output if it is established that the user has insufficient privileges to view the whole of the page.

There are also a number of methods that related to tag nesting, initialization, and reuse:

Tag getParent()void setParent()

The specification also requires methods to expose the parent property. A tag’s parent is the tag that directly encloses it in a JSP, or null if there is no enclosing tag. Tag implementations can query their parent at runtime, to obtain context information:

void setPageContext (PageContext pc)

setPageContext ( ) is an initialization method, making the PageContext of the JSP available to the tag.

void release ( )

release ( ) is a call to the tag handler to release any resources. Examples of this may be closing JDBC connections or open sockets that the handler requires for its function and to clear any state associated with it. The second is an often overlooked task in this context.

6.3.2 The javax.servlet.jsp.tagext.BodyTag Interface

BodyTag extends Tag, adding extra callbacks and other methods allowing the developer to work with the content of the tag.

A sequence diagram displays the interaction between calling JSP and tag handler in the case of a body tag; as you can see, it is somehow more complex than that of the Tag interface:

The extra steps involve the preservation of the JSP’s JSPWriter (messages 5 and 10), and the possibility of repeated calls to the doAfterBody( ) method, which enables the BodyTag implementation to take control of the tag’s execution at runtime.

The more significant methods of the BodyTag interface are listed below.

int doInitBody( ) throws JspException

Called after the tag has been initialized and doStartTag ( ) has been called. Its return value should be EAVL_BODY_TAG, in which case the tag’s body content and any child tags will be evaluated, or SKIP_BODY, in which case the body will be ignored. Watch out that you don’t try to return EVAL_BODY_INCLUDE from a BodyTag’s doInitBody ( ) or doStartTag ( ) methods. The JSP engine will throw a JspException if it detected this.

int doAfterBody ( ) throws JspException

doAfterBody ( ) is called each time the tag’s body has been processed. The return values are EVAL_BODY_TAG and SKIP_BODY. EVAL_BODY_TAG directs the JSP


Page 69: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

engine to evaluate the tag’s body and any child tags again (resulting in at least one more call to this method), SKIP_BODY, causes processing of the body content to terminate. This can be used to conditionally loop through the tag content.

void setBodyContent (BodyContent bodyContent)

Initialization method to set the class used to manipulate body content.

6.3.3 The javax.servlet.jsp.tagext.BodyContent Class

The BodyContent class is the key to BodyTag functionality. BodyContent is a subclass of JspWriter that can be used to manipulate the body content of BodyTag implementations and store it for later retrieval. The getBodyContent ( ) method of BodyTagSupport returns the BodyContent instance associated with a particular tag.

To understand the way in which the BodyContent class works, consider how JspWriter objects are handled in JSPs using BodyTags: messages 5 and 10 from the sequence diagram above. Before the BodyTag begins to evaluate its body content, the generated JSP implementation class includes the following line:

out = pageContext, pushBody ( );

After the BodyTag’s method have been called, it includes a matching call:

out = pageContext.popBody( );

What this means is that each BodyTag has a kind of play area, enabling it to manipulate its BodyContent without automatically affecting the JspWriter of the enclosing JSP page or tag. To generate output, the BodyTag needs to write the contents of its BodyContent into its enclosing writer explicitly (see below). This is the key difference between BodyTags and Tags: Tag implementations have no such (flexibility, and therefore cannot modify or suppress their body content, although they can prevent it from being evaluated altogether by returning SKIP_BODY in their implementation of doStartTag( ).

The most interesting methods in the BodyContent class are:

void clearBody( )

Clears the body content. Useful if we want to manipulate the body content before writing it out.

JspWriter getEnclosingWriter( )

Returns the enclosing JspWriter; this may be the writer of an enclosing tag, or the writer of a JSP itself. We normally use this method to get a JSP writer to which we can write the body content stored in a body tag when we have finished manipulating it. For example, we have used the following lines of code in the doEndTag ( ) method of a number of BodyTag implementation in this chapter:

BodyContent bodyContent = getBodyContent ( );if (bodyContent ! = null) { bodyContent.getEnclosingWriter(), write(s)bout.toString());


Page 70: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================


This ensures that if there is any body content held in the body tag, it will be written to the enclosing JSP writer.

String getString ( )

This returns the content already held in the body content, as a String. This is useful if we need to examine what has been added to the body content with each iteration of a loop.

6.3.4 Convenlence Classes

Some of the methods in Tag and BodyTag will be implemented the same way in most tags. So the javax.servlet.jsp.tagext package includes two convenience implementations of Tag and BodyTag: TagSupport and its subclass BodyTagSupport. Classes implementing tag extensions will normally be derived from one of these. The class diagram below shows the relationship between these classes and the Tag and BodyTag interfaces:

TagSupport and BodyTagSupport are concrete, not abstract classes, so they provide complete implementations of the corresponding interfaces, which do nothing except return the appropriate values to cause the JSP engine to continue rendering the page. So developers can safely omit methods that they are not interested in. Developers don’t usually concern themselves with handling the parent property and setPageContext ( ). The release ( ) method can also be omitted if it is not necessary to free resource or return the tag to its default state. The methods that a developer will normally want to override are doStartTag ( ) and doEndTag ( ) for all tags, and doInitBody ( ) and doAfterBody ( ) for BodyTags specifically.

TagSupport also makes an important convenience variable available to subclasses: pageContext (the saved PageContext which was set by the JSP engine when the tag was first used in a page). BodyTagSupport provides a getBodyContent( ) method, necessary to obtain a tag’s BodyContent before manipulating it.

Like me, you might find the names TagSupport and Body-TagSupport confusing. These classes are standard implementations of the Tag and BodyTag interface. It should be pointed out that this naming is inconsistent with Sun’s usual practice and Java convention; I think of them as TagImpl and BodyTagImpl.

6.3.5 The javax.servlet.jsp.tagext.TagExtraInfo Class

Metadata classes extending the TagExtraInfo abstract class may be associated with tag handlers to provide extra information to a JSP engine. This optional association is specified in the tag library descriptor.

We will look at the implementation of a TagExtraction class in more detail later in this chapter, but the two methods you are most likely to override are:

VariableInfo[ ] getVariableinfo (TagData td)

This method is used to return information about scripting variable that the tag makes available to JSPs using it. It returns an array of VariableInfo objects, which


Page 71: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

contain information about the name of each scripting variable and its fully qualified class name. It describes whether or not the variable should be declared or whether the tag will merely overwrite the value of an existing variable, and the scope of the variable.

Boolean isValid(TagData data)

This is sometimes used to validate the attributes passed to a tag at translation time. As an example, consider a tag with four attributes. Three may be optional, but if one of the optional attributes is specified the whole three must be present. There is no way to specify this behavior in a tag library descriptor. However, the isValid ( ) method of the appropriate TagExtraInfo subclass could be implemented to return false if the parameters supplied at translation time are invalid. The default implementation of isValid ( ) in TagExtraInfo always returns true. Note that runtime attribute validation is entirely different, and is the responsibility of the tag handler concerned.

6.3.5 Objects Available to Tag Handlers

All tag handlers have access to more context information than do most beans. This is available through the PageContext object they are passed on initialization. As you’ll recall, javax.servlet.jsp.PageContext is a convenient holder for information about the runtime of a JSP page, including the request and response object, and references to objects such as beans associated with the JSP.

This amount of access equals power. Note, though, that it is poor style to modify request and response directly from a tag handler. Custom tags should be thought of as generic building blocks intended for use in a wide variety of contexts. In practice tags should not be concerned with the parameters passed to the JSP page. Although a tag handler can access request parameters, relying on doing so will greatly reduce its reusability.

6.3.6 The Simple Example Revisited

To catch our breath after all this theory, let’s look again at the java implementation of the simple example we introduced earlier. We see that the tag handler extends TagSupport, and so gets most of its functionality for free. It has no state and access no file or other resources, so there is no need to override release( ). We use doEndTag ( ) to access the PageContext, obtain a JspWriter, and generate output:

package tagext;import java.io.IOException;import java.util.Date;import javax.servlet.jsp.*;import javax.servlet.jsp.tagext.*;

// Implementation of a tag to generate a single piece of HTML.public class HelloTag extends TagSupport{

// This method will be called when the JSP engine encounters the start

// of a tag implemented by this classpublic int doStartTag( ) throws JspTagException


Page 72: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

{// This return value means that the JSP engine should

evaluate// the contents and any child tags of this tagreturn EVAL_BODY_INCLUDE;

}// This method will be called when the JSP engine encounters the

end //of a tag implemented by this class public int doEndTag ( ) throws JspTagException

{String dateString = new Date ( ). toString ( );try{

pageContext.getOut().write("Hello world <br/>");pageContext.getOut().write("My name is " +

getClass().getName()+" and it's " + dateString + "<p/>");}catch (IOException ex)

{throw new JspTagException("Fatal error: hello tag

could not write to JSP out");}

// This return value means that the JSP engine should continue to

// evaluate the rest of this pagereturn EVAL_PAGE;}

} // class HelloTag

Note that we need to check for IOException when generating output. Any exception encountered while processing the tag must be wrapped as a JspException if it is so to be rethrown; it is good practice to use the javax.servlet.jsp.JspTagException subclass of JspException. (Note that, confusingly, this isn’t in the same package as the other classes specific to tag handlers.)

We could actually have omitted the doStartTag() method. I include it for completeness, but in fact it does exactly what its superclass TagSupport’s doStartTag() method does instruct the JSP engine to evaluate the tag’s content and any subtags.

6.4 Tag Library Descriptors

Tag Library Descriptors or TLDs are XML documents with a .tld extension that describe one or more tag extensions. TLDs must conform to the Document Type Definition (DTD) included in the JSP 1.1 specification. Many of the elements are intended to provide support for JSP authoring tools, although such tools are yet to be widely available in the market.

The root elements are<taglib>. It’s defined in the DTD by:

<!ELEMENT taglib (tlibversion, jspversion?, shortname, uri?, info?, tag+) >

tlibversion is the version of the tag library implementation. This is defined by the author of the tag library.


Page 73: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

jspversion is the version of JSP specification the tag library depends on. At the time of writing the value you should use is 1.1 (the default). The element is optional.

shortname is a simple default name that could be used by a JSP authoring tool; the best value to use is the preferred prefix value: that is, a suggestion as to a prefix to use when importing the tag library. Although there is no way of enforcing this, hopefully developers using the library ill follow this suggestion, and consistency will be achieved between all users of the tag library. The shortname should not contain whitespace, and should not start with a digit or underscore.

uri is an optional URI uniquely identifying this tag library. If it is used, the value will normally be the URL of the definitive version of the tag library descriptor.

info is an arbitrary text string describing the tag library. Think of it as the equivalent of a Javadoc comment relating to an entire class or package; the authoring tool may display it when the tag library is imported.

The <tag> element is the most important. It’s defined in the DTD as:

<!ELEMENT tag (name, tagclass, teiclass?, bodycontent?, info?, attribute?) >

name is the name that will identify this tag (after the tag library prefix0.

tagclass is the fully qualified name of the tag handler class that implements this tag. This class must implement the javax.servlet.jsp.tagext.Tag interface.

teiclass stands for TagExtraInfo class, and defines the subclass of javax.servlet.jsp.tagext.TagExtraInfo that will provide extra information about this tag at runtime to the JSP. Not all tags require a TagExtraInfo class.

bodycontent is an optional attribute specifying the type of body content the tag should have. Three values are legal: tagdependent, JSP, and empty. The default (and more useful) to JSP, which means that the tag’s body content will be evaluated at run time like any other JSP content. tagdependent signifies that the JSP engine should not attempt to evaluate the content, but accept that while it may not understand it, it means something to the tag handler, and should therefore be passed unchanged. empty is useful when a tag should not have any body content. If this value is used, and the tag is not empty, JSP translation will fail.

<attribute> sub-elements describe each attribute accepted (or required) by the tag. The DTD definition is:

<!ELEMENT attribute (name, required?, rtexprevalue?) >

name is the name of this attribute, as it will appear in JSPs using the tag.

required specifies whether or not this attribute is mandatory. The valid values are true/the attribute is required), and false (the default, signifying an optional attribute). The attribute may have a default value.


Page 74: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

rtexprvalue specifies whether the attribute value can be the result of a JSP expression, or whether it has a fixed value at translation time when the tag is used in a JSP. Valid values are true and false. Again, the default is false, meaning that expression are forbidden . If rtexprvalue is true, the following will be legal.

<examples:mytag attrib”<%-myObject.getValue()%>’>

Allowing attributes to take expression values can be very useful. Setting attributes by the use of expression allows their behavior to be determined at runtime. For example, very often tag attributes will be set to the value of properties of JSP beans. This relies on the use of a JSP expression.

The simple example’s TLD was very straightforward. As this tag takes no attributes and has no associated TagExtraInfo class, only the bare minimum of elements is required:

<?xml version=”1.0” encoding=”ISO-8859-1” ?> <!DOCTYPE taglib

PUBLIC “-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN” http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_.dtd> <taglib> <tlibversion>1.0</tlibversion> <jspversion>1.1</jspversion> <shortname>examples></shortname> <tag> <name>hello></name> <tagclass>tagext.HelloTag</tagclass> <bodycontent>JSP</bodycontent> <info>Simple example</info> </tag> </taglib>

Although the XML structure is not complex, and at present TLDs will usually be written by hand, as JSP 1.1 becomes more widely supported tool support can be accepted. This will synchronize TLDs and the relevant Java classes, avoiding time-wasting trivial errors.

6.5 Using Tag Extensions in JSP Pages

Unlike the standard actions such as <jsp:forward>, custom tags must be explicitly imported into JSP pages that wish to use them. The syntax for the taglib directive is shown below:

<%@ taglib uri=”http//www.tagvendor.com/tags/tags.tld” prefix=”example” %>

The uri attribute tells the JSP engine where to find the TLD for the tag library. The prefix attribute tells the JSP engine what prefix will be given to tags from this library in the remainder of the JSP.

A JSP may import any number of tag libraries. The taglib directive will cause an exception at translation time if the tag library cannot be located; the first attempted access to any tag defined in the TLD will cause an exception at runtime if all the classes required to support the tag implementation cannot be loaded.

Once the tag library has been imported into the page, tags in a library can be called as follows:


Page 75: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

<examples:someTag name=”Rod”>. . .</examples:someTag>

The way in which custom tags are used in JSP is an example of Sun’s efforts to introduce XML conventions into JSP syntax. Note that, unlike HTML attributes, the attributes of custom tag must be enclosed in double quotes, in accordance with the XML specification. (of course it is good practice to write XML complaint HTML markup, but browsers do not currently enforce it.) Tag prefixes use the same syntax as XML namespaces.

When a tag requires no body content, it is best to use the XML shorthand to make this explicit:

<examples:hello name=”Rod” />

Tag prefixes are defines in JSPs, not, as one might expect, in tag libraries. Choice of prefix is a matter for developers, but consistency among JSP pages importing the same tag library is advisable. It is best to adopt the value of the shortname element in the tag library. The prefixes jsp;, jspx;, java;, javax;, servlet;, sun;, and sunw: are reserved. It’s perhaps unfortunate that Sun has not defined a unique naming system such as the Java package naming system for tag library prefixes. Choosing a prefix unique to a company or organization is advisable: for example, instead of using the potentially clashing short name tables, it might be advisable to use myCompany_tables.

6.6 Deploying the Packaging Tag Libraries

There are three main ways of deploying and using tag libraries with a JSP engine. JSP developers must be familiar with all three, because each of them calls for slightly different syntax in the taglib directive. (This means that JSPs need to be modified slightly if they are to be deployed in a different way – surely an oversight in the JSP specification.)

6.6.1 No Packaging

The first and simplest means of deployment is simply placing the tag library descriptor under the server’s document root, and the Java classes required to implement the tags in the server (or system) classpath. There is no attempt to package a tag library or an application. In this case, the taglib directive will look like this:

<%# taglib uri=”./hello.tld” prefix=”examples” %>

The uri is simply a path on the host server, which may be relative (as in this example) or absolute. In this approach, the tag library descriptor (although not the classes implementing the tag handler) is always publicly available: anyone could view it by simply typing in its URL. This approach is easy to work with, but can create problems at deployment time: the JSP engine or system’s classpath has to be hand edited to include the classes implementing the tag.

6.6.2 WAR

In a second approach to deployment, the tag library descriptor, the Java classes required to implement the tags, and the JSPs that use the tag library can be


Page 76: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

shipped together as a web application, in a Web Archive file (better known a WAR file). This is the approach we’ve taken in this chapter. It is very attractive because it offers painless portability between servers and very easy deployment. In this case, the taglib directive will look like this:

<%@ taglib uri=”/hello” prefix=”examples” %>

Note that we don’t specify the actual filename of the TLD, so there is no need to use the TLD extension. This server knows where to look in the current web applications WAR for a .tld file matching this URI because the mapping from URI to file location is specified in the web.xml file in a <taglib> element. The complete web.xml file for our simple example looked like this:

<?xml version=”1.0” encoding=”UTF-8?>

<!DOCTYPE web-app PUBLIC `-//Sun MicroSystem, Inc.//DTD Web Application 2.2//EN’’ http://java.sun.com/j2ee/dtds/web-app_2.2 .dtd’>

<web-app> <display-name>tagext</display-name> <description>Tag extensions examples</description>

<session-config> <session-timeout>0</session-timeout> </session-config>

<taglib> <taglib-uri>/hellovar</taglib-uri> <taglib-location>/WEB-INF/hello.tld</taglib-location> </taglib>


The <taglib> element contains two subelements<taglib-uri> specifies the URI that should be used is JSP’s wishing to use the tag library; <taglib>-location> specifies the path to the tag library descriptor relative to be web.xml file. Note that this path need not be publicly available to users of the web server; the server will not publish anything that is in the WEB-INF directory.

Remember the important directories in the WAR.

WEB-INF:This contains the web.xml file, in which the TLD URI-location mapping must be specified.

WEB-INF/classes:This contains Java classes required to implement tag libraries or otherwise support the functionality of the web application.

WEB-INF/lib:This contains JAR files containing additional classes required to support the functionality of the web application.

WEB-INF/tlds:By convention (although not mandated in any specification) this contain the tag library description (but not tag handler classes) that will be made available to JSPs in the web.xml file. The TLDs could actually be placed anywhere in the WAR (so long as a mapping is included in the web.xml


Page 77: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

file), but adhering to this convention makes it easier to comprehend the WAR’s structure.

Chapter: 7


Topics Discussed

Introduction to Databases Database Design Two-Tier Database Design Three-Tier Database Design Overview of ODBC (Open Database Connectivity) Overview of JDBC API How does JDBC work? Security Model JDBC API Components The java.sql Package Literals Variables JDBC Drivers

Type 1: The JDBC-ODBC Bridge Driver Type 2: The Native Library-to-Java Driver Type 3: The Network Protocol Driver Type 4: The Native Protocol Driver Executing SQL Commands Using JDBC drivers Using Type 1 Driver (JDBC ODBC Bridge Driver) Using Type 2 Driver (The Native Library-to-Java Driver) Using Type 4 Driver (The Native Protocol Driver) The ResultSetMetaData Interface

7.1 Introduction to Databases

Data are raw facts from which information can be derived. A database is a record-keeping system of an organization, more specifically a computer-based system, the purpose of which is to record, and store data. A database can be defined as a collection of stored operational data used by the application systems of some particular enterprise.

A database is a collection of interrelated data from which some information can be extracted. The collection of data must be logically coherent with some inherent meaning. A database is designed and built for a specific purpose, keeping in mind the needs of the applications that are going to use it and the end users of those applications. A Database is like a data file, a data storage place. Alike a data file, a database does not present information directly to a user. The user runs an application that accesses data from the database and after analyzing


Page 78: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

it, presents it to the user in a useful format. Databases systems are more powerful than data files because data is more highly organized. In a well-designed database, there are no duplicate pieces of data, the user or application has to update at the same time. Related pieces of data are grouped together in a single table, and the relationships between tables can be precisely defined. A database typically has two components: the files holding the physical database and the Database Management System (DMBS) software that application use to access, process, format, and output data. A DBMS is a general-purpose software system that enables users to define and manipulate databases. It provides an environment wherein data can be stored and retired from databases easily and efficiently.

A Relational Database Management System (RDBMS) is a database based on the relational model invented by E.F. Codd at IBM in 1970. It allows definition of data structures, storage and retrieval operations and integrity constraints. An RODMS can be thought of a DBMS with add on facility of setting relations between databases, and hence at one instance of time you can use information across tables.

7.2 Database Design

A Database Design can be categorized into three parts:

Single Tier Database Design Two-Tier Database Design Three-Tier Database Design

Monolithic, Single Tier Database Design

In the beginning of the RDBMS era, the RDBMS applications were based on an integrated model where the user interface code, application code, and the database libraries were bundled together. The applications ran only on a local machine and did not work on local-area networks. There was often, contention between instances of the application because the monolithic approach did not allow multiple instances of the application to communicate with each other. The following figure depicts a monolithic, one-tier database design:

Fig. 7.1The one-tier database design



Application Database Libraries

Page 79: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

7.2.1 Two-Tier Database Design

The evolution of the two-tier design is due to the server technology. In this model, the application accesses data through a server. The application is considered as a front-end and the server as the back-end. The front-end applications are stored in the client side and the database is stored on the server. The client software is connected to the database through a socket connection.

In this model the clients send requests to the database server through SQL (Structured Query Language). The server sends the results according to the request and the client is responsible for formatting the data. The communication between the client and server takes place with the help of a vendor-provided library of functions. These functions are written in the C language.The following figure depicts a two-tier database design.

Fig.7.2Two-Tier Database Design

7.2.2 Three-Tier Database Design

This design is not limited to only three tiers. In a multi-tier design, there is an intermediate server in addition to the client and the database server. The client communications with the intermediate server. The intermediate layer is used to handle multiple client requests and manage the connection to one or more database servers.The following figure depicts the three-tier database design:

SQL Request

Data Reply

Change Notification


Application (Client)

Client-side Libraries

Database Server


Application (Client)

Client-side Libraries


Business Rules

Client-side Libraries




Page 80: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Fig. 7.3Three-Tier Database Design

Since, every organization maintains data pertaining to its business, employees, and clients in a database using some DBMS or ROBMS package, it is of vital importance that we have some mechanism to connect to the database using the programming languages at our disposal. Over the years we have had many approaches to establish connection with database but a few have stood the test of time. Let us go through a few of the more successful approaches for database connectivity.

Note In two-tier and three-tier systems, an application is logically divided into three parts:

GUL, Graphical User Interface: Consists of screens, Windows, buttons, list boxes and more.

Business Logic: This is the part of the program that deals with interaction between various data elements, for example, calculation or credit limit based on the annual salary, etc.

DBMS The database management system, that deals with the actual storage and retrieval of data.

7.3 Overview of ODBC (Open Database Connectivity)

ODBC is a database interface used to interact with databases from a programming language through its functions. It is Microsoft’s implementation of the X/Open and SQL Access Group (SAG) Call Level interface (CLI) specification. The functions of ODBC include adding, modifying and deleting data and obtaining details about the databases, tables, views, and indexes. An ODMC application has five layers (shown in Figure 7.4): Application Layer ODBC Interface Layer Driver Manager Layer Driver Layer Data Source Layer

Fig. 7.4ODBC Architecture

Application Layer




Driver Manager


Data Source

Page 81: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The Application Layer provides GUI and Business logic, written in languages like Java, Visual Basic and C++.

ODBC Layer

The Application layer uses the ODBC functions defined in the ODBC interface to interact with the databases.

Driver Manager Layer

The Driver Manager Layer manages the loading of various drivers available in the system, directing calls to the right driver, and providing driver information to the application when required. The driver manager ensures that the right database management system gets all the program calls directed to it and that the data from the data source is routed to the application when an application is connected to more than one database.

Driver Layer

This layer is the actual component, which knows about specific databases. The driver is assigned to a specific database like the Access Driver, SQL Server Driver, and Oracle Driver. It is the duty of Driver Layer to implement all the functionality provided by the ODBC interface like SQL statement calls, connection management calls, information about the database and so on. This indicates that the Driver has to emulate the ODBC interface functions not supported by the underlying DBMC for some databases. The other duties of this layer include sending queries to the databases, receiving the data back, and routing the data to the application. The Driver layer also handles the network communication for databases that are in the local networked system or on the internet.

Data Source Layer

In the content of ODMC, the Data Source can be a database management system, or the data store, which is usually a set of files on the hard disk. It can be the Microsoft Access database, the SQL Server database or the Oracle database.

7.4 Overview of JDBC API

JDBC stands for Java Database Connectivity. It was developed by JavaSoft and is a part of the Java Enterprises API. JDBC is the first standardized API that allows the users to develop database front ends without continuously rewriting their code. JDBC provides the ability to create robust, platform-independent applications and Web-based applets, which can access any database through a DBMS-independent mechanism. The interaction between these applications and applets with SQL data sources is done through a set of relation database objects and methods defined in the JDBC API.

7.4.1 How does JDBC work?

A set of API objects and methods, defined in JDBC, are used to interact with the underlying database. At the beginning of the process, a Java program open a connection to a database. Then, it creates a statement object, passes SQL statements to the underlying DBMS through the statement object, and retrieves the results and information about the result sets. The JDBC class files and the Java applets reside in the client. They can be downloaded from the network also. It is better to have the JDBC classes in the client to minimize the latency during execution. The DBMS and the data source are typically located in a remote server. The applet and the JDBC layers communicate in the client system, and interact with the database over the network.


Page 82: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

7.4.2 Security Model

Security is very important especially when databases are involved. As far as JDBC is concerned, it follows the standard security model in which applets can connect only to the server from where they are loaded. Remote applets cannot connect to local databases. Applications have no connection restrictions. The security check is automatic as far as pure Java drivers are concerned. The drivers must have security checks if they are developed through native methods.

7.4.3 JDBC API Components

The JDBC API has two levels of interface: the Application Layer and the Drive Layer. The Application Layer allows the developer to make calls to the database via SQL and retrieve the results. The Driver Layer handles communication with a specific driver implementation. The Driver Layer must implement for interfaces and one class. The class bridges the Application Layer and the Drive Layer. The four interfaces are Driver, Connection, Statement, and ResultSet. The connection to the database is made by the Driver interface. The developer has one more layer of abstraction, i.e. the DriverManager Class. In most applications, the Driver is accessed through the DriverManager class.

The interfaces like Connection, Statement and ResultSet represent methods that allow the developer to create statements and retrieve results. The Driver and Application layers allows the developer to create database applications without knowing details i.e., from where the objects are coming or what type of driver the application will use. The following section describes about the implementation of the JOBC API classes and interfaces.

7.5 The java.sql Package

The implement of JDBC is made through the java.sql package. This package contains all the JDBC classes and methods that allow the developer to create database applications. The topmost class in the class hierarchy of JDBC classes is the Driver/Manager, which keeps to our information, state information and more. When each driver is loaded, it is registered with the DriverManager. Whenever a connection is made, the Driver/manager selects the driver on the JDBC URL.

The JDBC URL is a string that is used by the drivers and access databases. The syntax of a JDBC URL is:


The <subprotocol> defines the type of driver and <subname> provides the network-encoded name. For example:


In the above example, the database driver is an Oracle driver and the subname is a local database called customer.

For databases on the Internet or intranet, the subname can contain the net URL //hostname:port/. For example



Page 83: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

In the above example, the mysql is the database driver type, which locates a server named dbserver in the eng domain and attempts to connect to a database server on the port 812 that contains a burgerports database using the default username and password.

The java-sql.Driver Interface

JDBC drivers implement the Driver interface. Writing a JDBC driver consists of a creating a Java class that implements the Driver interface. Although you do not have to worry about writing your own JDBC driver. Table below lists the methods defined in this class.

Methods DescriptionConnection connect(String url, Properties into) throws SQLException

This method first checks the sub-protocol name of the URL string passed for a match this driver. The Driver then attempts to make a connection to the database using the remaining part of the URL. If the connection is successful, this method will return an instance of the Connection class. It throws an SQLException only if the driver recognizes the URL subprotocol but cannot make the database connection. The second parameter info contains the username and password.

Boolean acceptsURL(String url) throws SOLException

The method returns true only if the URL is valid. It checks only the sub-protocol specified in the URL, not whether the connection can be made.

The most important method is the connect( ) method, which is invoked for the driver by the Driver/Manager to obtain a Connection object is the starting point of the JDBC Application. This object is used to create Statement objects that perform the queries.

The DriverManager class (java.sql.DriverManager)

This class controls the coding of driver specific classes. The JDBC drivers are actually managed by the utility class. DriverManager. This class provides methods that allow the user to obtain a connection through a driver, register and de-register drivers, set up logging, and set login timeouts for database access. As the methods in this class are static and hence they have to be referred to through the class name. Table below lists the methods defined in this class:

Methods DescriptionConnection getConnection( String url, Properties info ) throws SQLException

This method returns a reference to a Connection object implemented from the Connection interface. The parameter info is a reference to a Properties object, which contains the username and password.

Connection getConnection(String url) throws SQLException

This method returns a Connection object by calling the getConnection(url,info) with the empty Properties object (info).

Connection getConnection( String url, String user, String password) throws SQLException

This method first creates a Properties object (info), stores the user and password strings into it and then calls getConnection (url, info).

void registerDriver

(Java.sql.Driver driver) throws SQLException

This method stores the instance of the Driver into a vector of drivers along with an instance of SecurityContext, which identifies where the driver came from.


Page 84: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

void setLogStream( java.io.PrintStream out)

This method sets a private, static java.io.PrintStream reference to the PrintStream object passed to the method.

The drivers are registered with the Drive/Manager at the time of initialization of the DriverManager class or at the time of creating an instance of the driver. Actually, each driver name is a class filename and these class names of drivers are listed in a Java property named jdbc.drivers, which are loaded when the DriverManager class is loaded. This property can be used to define a list of colon-separated driver class names, such as;


The DriverManager uses the following call to locate, load, and link the named classes through the current CLASSPATH:

Class.forName (driver);

The application must create an instance of a driver class if the jdbc.drivers property is unspecified. The driver class is created by implementing the interface Driver. In both cases, the implementation of the Driver class must register itself with the DriverManager by calling the registerDriver() method, as follows:

DriverManager.registerDriver (this);

The Connection interface

One of the major interface in JDBC API is the connection interface, which represents a session with the database connection provided by the Driver. The functionalities of this class range from transaction processing to creating statements. Once the user gets a Connection object form the driver, the user should set the auto-commit mode of false since JDBC connections are in auto-commit mode by default. The connection will support commit and rollback methods when the auto-commit mode is disabled. Table below lists the method defined in this class:

Methods DescriptionStatement createStatement() throws SQLException

This method returns a Statement object, which is then used to issue queries.

PrepareStatement prepareStatement ( String sql ) throws SQLException

This method returns a PrepareStatement object that is configured with the sql string. The Driver may then send the statement to the database, if the database(driver) handles precompiled statements. Otherwise, the driver may wait until the PreparedStatement is executed by an execute method. The SQLException might be thrown if the driver and the database do not implement precompiled statements.

CallableStatement prepareCall(String sq ) throws SQLException

This method returns a CallableStatement object, which is used to handle stored procedures. The sql string is sent immediately through the driver when prepareCall() is complete or may wait until an execute method occurs.

void setAutoCommit( Boolean commit-mode ) throws SQLException

This method is used to set a flag in the driver that enables commit (true)/rollback(false) or makes all transactions commit immediately.


Page 85: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

void commit() throws SQLException

This method takes care of all changes made since the beginning of the current transaction.

void rollback() throws SQLException

This method is used to drop all changes made since the beginning of the current transaction.

DatabaseMetaData getMetaData()

This method is used to return a DatabaseMetaData object which is associated with the information about the whole database, including access information about tables and procedures, column names, datatypes and so on.

The Statement interface

The Statement object is used to interact with the Database Management System in terms of SQL statements. In other words, the statement object sends the SQL queries to the database and retrieves results. The user can create many Statement objects from the Connection object. The Statement object is associated with various data needed to interact with a database, including state information, buffer handles, and so on. But these are transparent to the JDBC application program. Statements can be SQL updates, insertions, deletions or queries. Table below lists the methods defined in the Statement interface that allow the developer to make the job of writing queries to the database easier.

Methods DescriptionResultSet executeQuery (String sql0 throws SQLException

This method is used to execute a SQL query and return a ResultSet object.

int executeUpdate( String sql ) throws SQLException

This method is used to execute a SQL query and return an integer that represents the affected rows. This method can be used in situations where no results are expected except a row-count status.

boolean execute(String sql ) throws SQLException

This method can be used when a SQL statement returns single or multiple result sets or update counts. This method can also be used to execute stored procedures that return Out and InOut parameters. To retrieve the data returned, the methods getResultSet(), getUpdateCount(), and getMoreResults() are used.

ResultSet getResultSet() throws SQLException

This method is used to return the current data as the result of a statement execution in the form of a ResultSet object. The method returns a null if there are no results to be read or if the result is an update count. The important point to note is that once the result is read, it is cleared.

int getUpdateCount() throws SQLException

This method returns the status of an Update, Insert, and Delete query or a stored procedure that returns a row status. The method returns –1 if there is no update count or the data returned is a result set. The update count will be cleared once it is read.

boolean getMoreResults() throws SQLException

This method is used to return true if the next result is a ResultSet object. The method moves to the next result in a set of multiple results/update counts. once read, the previous ResultSet will be closed.

JDBC supports two more types of statement objects in addition to the statement object. They are PreparedStatement and CallableStatement.In the case of a PreparedStatement object, as the name implies, the application program prepares a SQL statement using the java.sql.Connection.prepareStatement() method. The PrepareStatement() method takes a SQL string, which is passed to the underlying DBMS. The DBMS goes


Page 86: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

through the syntax run query plan optimization, and the execution plan that the JDBC driver stores internally in the Prepare/Statement object.

The methods of the PreparedStatement object such as executeQuery(), executeUpdate(), and execute() methods are just calls to the underlying DBMS to perform the already-optimized SQL statement.

For a secure, consistent, and manageable multi-tier client/server system, to data access should allow the use of stored procedures. Stored procedure centralizes the business logic in terms of manageability and also in terms of running the query. Java applets running on clients with limited resources cannot be expected to run huge queries. But the results are important to those clients. JDBC allows the use of stored procedures, by the CallableStatement interface, with the escape clause string.A Callable/Statement object is created by the prepareCall() method in the Connection object. The prepareCall() method takes a string as the parameter. This string, called an escape clause, is of the form

{[?=] call <stored procedure name> [<parameter>,<parameter> . . .]}

where the question mark symbol(?) is the placeholder for the parameters/

The CallableStatement interface supports parameters. These parameters are of the OUT kind from a stored procedure or the IN kind to pass values into a stored procedure. The parameter marker (question mark) must be used for the return value (if any) and output arguments because the parameter marker is bound to a program variable in the stored procedure, input arguments can be either literals or parameters. For a dynamic parameterized statement, the escape clause string takes the from

{[“=] call <stored procedure name> [<?>, <?> …]}

The OUT parameters should be registered using the registerOutParameter() method as shown in table below before the call to the executeQuery(), executeUpdate(), or execute() methods.

In the JDBC call, you create a CallableStatement object with the “?” symbol as a placeholder for parameter, and then connect Java variables to the parameters.

Methods Descriptionvoid registerOutParameter (int parameterIndex, int sqlType)

This method is used to tie the placeholders with actual parameters. The argument parameterIndex depicts the position of the question marks and SqlType defines the SQL datatypes that are returned as Out parameters.

The CallableStatement interface defines the getType methods and the PrepareStatement interface defines the setType methods. The setType methods are used to set the values of the parameters marked in the SQL statements with question marks (?) whereas the getType methods are used to convert the SQL types returned from the database to Java types. Tables below defines the setType methods and the getType methods.

setType Methods

Method Java Type SQL Typevoid setByte(int index, byte b) Byte TINYINT

void setShort(int index, short x) short SMALLINT


Page 87: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

void setInt(int index, int I) int INTEGERvoid setLong(int index, int I) long BIGINTvoid setFloat(int index, int f) float FLOATvoid setDouble(int index, int d) double DOUBLEvoid setBigDecimal9int index, BigDecimal x)

java.lang.BigDecimal NUMERIC

void setString(int index, String s) java.lang.String VARCHARvoid setAsciiStream(int index,InputStream x, int length)


void setUnicodeStream(int index, InputStream x, int length)

java.io.InputStream LONGVARCHAR

void setBytes(int index, byte x[]) byte array VARBINARYvoid setBinaryStream(int index, InputStream x, int length)

java.jo.InputStream LONGVARBINARY

void setDate(int Index, Date d) java.sql.Date DATEvoid setTime(int index, Time t) java.sql.Time TIMEvoid setTimestamp(int index, Timestamp ts)

java.sql.TimeStamp TIMESTAMP

void setNull(int index, int sqlType) java.sql.Types has contains for each of the SQL types.

void setBoolean(int index, boolean b)

boolean BIT

getType Methods

Method Java Type SQL Typeboolean getBoolean(int index)

Boolean BIT

byte getByte(int index) Byte TINYBITshort getShort(int index) short SMALLINTint getInt(int index) int INTEGERlong getLong(int index) int BIGINTfloat getFloat(int index) float FLOATdouble getDouble(int index)

double DOUBLE

BigDecimal getBigDecimal(int index, int scale)

java.lang.BigDecimal NUMERIC

String getString(int index) string CHAR, VARCHAR, or LONGAVARCHAR

byte[] getBytes(int index) Byte array BINARY, or VARBINARYDate getDate(int index) java.sql.Date DATETime getTime(int index) java.sql.Time TIMETimeStamp getTimeStamp(int index)

java.sql.Timestamp TIMESTAMPA

The ResultSet interface (java.sql.ResultSet)

The data from tables are accessed through the methods defined in the ResultSet interface. Actually the data from tables are generated by executing Statement. This class stores the results of the statements created. The ResultSet column values are indexed and hence they may be accessed in any order. Also, they can be selected either by name or the number of the column. The ResultSet values are indexed and hence they may be accessed in any order. Also, they can be selected either by name or the number of the column. The ResultSet object


Page 88: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

maintains a cursor indicating the position of the current row. Table below defines the methods of the ResultSet interface.

Method Descriptionboolean next() throws SQLException

This method sets the position of the ResultSet to the next row. Initially the ResultSet row position is the first row of the result set.

ResultSetMetaData getMetaData() throws SQLException

This method is used to main an object this is associated with the description of the current result set. The description includes the number of columns, the type of each column, and properties of the results.

void close(0 throws SQLException

This method is used to release the resources associated with the ResultSet.

Now that you have been introduced to the various classes and interfaces of JDBC APL. Before explaining the examples, which demonstrates the usage of the methods, you must be clear with the JDBC drives through which the JDBC application runs.

7.6 JDBC Drivers

There are a number of drivers available from database vendors and third-party developers. But, it is always wise to have the drivers that have the best features, are cost effective and provide customer support. There are a variety of drivers available according to the type of database they are intending to support. JavaSoft categorizes database drivers in four ways:

7.6.1 Type 1: The JDBC-ODBC Bridge Driver

The first type of JDBC driver is the JDBC-ODBC Bridge. This driver type is provided by Sun with the JDK1.1 and later. It is a driver that provides access to database through ODBC drivers. For that the ODBC driver must be configured on the client for bridge to work.

Developers can use the JDBC-ODBC bridge driver instead of other JDBC drivers since applications will speak directly to JDBC interface classes. Also, developers should be aware of the requirements to run the applications when the JDBC-ODBC bridge is implemented and the clients must have a local copy of the ODBC driver, the ODBC driver manager, and client-side libraries since ODBC calls are made using binary C calls. Figure 7.6 shows the driver interaction of the JDBC-ODBC Bridge.

7.6.2 Type 2: The Native Library-to-Java Driver

To translate JDBC to the native client library, the Native Library-to-Java Driver uses native C language library calls. These drivers use C language libraries that provide vendor-specific functionality and tie these libraries to the JDBC. These drivers were first available for Oracle, Sybase, Informix, and other client-library-based RDBMSs. Figure 7.6 shows the interaction of the Native Library-to-Java Drive.


SQL Command Result




Application Space

Java Application

Type 2 Jdbc Driver

Native Database Library



Page 89: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Fig. 7.6The Native library-to-Java Driver

7.6.3 Type 3: The Network Protocol Driver

The JDBC-Network protocol drivers are a three-tier solution. This type of driver translates JDBC calls into a database-independent network protocol that is sent to a middleware server. This server then translates this DBMS-independent protocol into a DBMS-specific protocol, which is sent to a particular database. The result is routed back through the middleware server and sent back to the client. This type of solution makes it possible to implement a pure Java client. It makes it possible to swap database without affecting the client. This is by far the most flexible JDBC solution.


SQL Command Result




Application SpaceJava Application

Type 3 Jdbc Driver


Middleware Space

JDBC Driver

Page 90: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Fig. 7.7The Network protocol Driver

7.6.4 Type 4: The Native Protocol Driver

The Type 4 drivers are pure Java drivers that communicate directly with the vendor’s database. This is done through converting JDBC commands directly into the database engine’s native protocol. The type 4 Driver has a very distinct advantage over all the other driver types. It has no additional middleware layer, which improves performance tremendously. Figure 2.8 shows the communication of a Type 4 driver.

Fig. 7.8The Native Protocol Driver

7.7 Executing SQL Commands Using JDBC drivers

7.7.1 Using Type 1 Driver(JDBC ODBC Bridge Driver)

Before you start writing the programs using Type 1 Drivers, create a table inside the Oracle database with the name emp. Add fields ENAME, EMPNO, DESIG, HIREDATE and DEPTNO.

Now let us start making the programs

Program to retrieve the result from the Table

The following program executes a SQL SELECT statement to list all the employee in the database.


SQL Command ResultUsing Proprietary Using ProprietaryProtocol Protocol

Application Space

Type 4 JDBC Driver

Java Application


Page 91: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

import java.sql.*;class sqldemo1{ public static void main(String a[] ) throws Exception {

int StNo;String StName;Connection Conn;Statement Stmt;ResultSet rs;//Initialize and load the JDBC-ODBC driver.Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");// To get a database connectionConn =DriverManager.getConnection("jdbc:odbc:empDB");//To create a statement object to execute the SQL statementStmt = Conn.createStatement();//Sends the SQL statement to the DBMS and executivers = Stmt.executeQuery("select empno, empname from emp");//Processing the resultsSystem.out.println("Empno "+" Name ");while(rs.next()) {

StNo = rs.getInt(1); StName = rs.getString(2);

System.out.println(StNo+"\t"+StName); }

}}The output is as shown in Figure 7.9.

Fig. 7.9 Output of the program

While creating the above program, the following steps have been followed:

Step 1: The program initializes and loads the JDBC-ODBC driver using the static method forName() of the class Class.

Step 2: The program calls the getConnection() method to get the Connection object.

Step 3: With the help of the object created in step 2, it invokes the method createStatement() to create the Statement object and prepares SQL treatment.

Step 4: With the help of the Statement object, you then invoked the executeQuery() method of the Statement interface, passing it the Select empno and empname From emp SOL statement as an argument. This resulted in the query being processed by the database and a ResultSet object being returned.


Page 92: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Step 5: A ResultSet object maintains a pointer to a row within the tabular results. The pointer is referred to as a cursor. When a ResultSet object is returned from a query, the cursor initially points immediately before the first row of the table. The next () method of the ResultSet interface is used to move the cursor to the next row of the table. The next () method returns a boolean value is true if the next row is returned and false it the end of the table is reached. Hence, each how is processed until there are no more rows.

Note: The odbc subprotocol name is reserved for ODBC style data sources. A normal ODBC databases JDBC URL locks like the following:

jdbc:odbc:<ODBC DSN>;User=<username>;PW=<password>

That is, when you use the jdbc:odbc driver, the JDBC url should contain a data source name (DSN), user ID, and password for the ODBC data source. It must be initialized and loaded with the following method as described earlier:

Class.forName (“sun.jdbc.odbc.JdbcOdbcDriver”);

In the next example the first three steps will be the same.

Program to Update the Table

The following program is used to update the name and addr of the student whose number is 2.

import java.sql.*;class OraSqlUpdate{ public static void main(String a[] ) throws Exception {

int StNo;String StName;Connection Conn;Statement Stmt;ResultSet rs;//Initialize and load the JDBC-ODBC driver.

Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");

// To get a database connectionConn =DriverManager.getConnection("jdbc:odbc:OraDsn","scott","tiger");//To create a statement object to execute the SQL statementStmt = Conn.createStatement();//Sends the SQL statement to the DBMS and executiveint n= Stmt.executeUpdate("Update stud set name='yanu', addr='China'

where no=2");System.out.println("Number of records updated is "+n);


The output is as shown in Figure 7.10.


Page 93: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

Fig. 7.10Output of the program

In the code given above, the UpdateName () method has been created, which updates the empno and empname of a particular employee, whose name is passed as an argument.

While creating the above program the first three steps, which we followed in the previous example, are the same. The only difference is in fourth and fifth step. Here instead of executeQuery(), the method executeUpdate() has been invoked. The executeUpdate() method of the Statement interface takes in the SQL Update statement as an argument and returns an integer value representing the number of rows updated. In the above code it returns 1.

The following section describes the usage of PreparedStatement and CallableStatement interfaces in programs. As discussed earlier, the PrepareStatement interface provides an efficient mechanism for passing a precompiled SQL statement that uses parameters. You have to use the setType methods defined in Table 1.6 in the following programs, since the PreparedStatement parameters are considered as In (input) parameters and they have to filled in using the setType methods.

Programs to insert the row using PreparedStatement interface

The following program inserts rows in the Students table where you can see the usage of the PreparedStatement parameters:

import java.sql.*;public class preparedmo1{

public static void main(String a[]) throws Exception{

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");Connection c = DriverManager.getConnection("jdbc:odbc:OraDsn",

"scott", "tiger");PreparedStatement p1 = c.prepareStatement("Create table

Empl(Name varchar2(30),No number(10))");p1.executeUpdate();PreparedStatement p = c.prepareStatement ("insert into Empl

values(?, ?)");

p.setString (1, "soma"); p.setInt (2,1000);



Page 94: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

System.out.println("value inserted");}


The output is as shown in Figure 7.8.

Fig. 7.8Output of the program

In the code given above, after initializing and loading the Driver the prepareStatement() method is invoked using the object of the Connection interface. This method returns the object of the PreparedStatement interface, which is used with parameterized SQL statements. These parameterized SQL statements replace a constant SQL statement with a question mark(?), which is called an IN parameter. The PreparedStatement provides several set methods for setting the values of IN PARAMETERS. These methods are organized into the type of value to which a parameter is to be set.Further, the executeUpdate() method of the PreparedStatement interface has been invoked to execute the SQL statement, which is passed as an argument to the prepareStatement() method.

Program to invoke a stored procedure using CallableStatement interface

Now, we will see the usage of the CallableStatement interface. As discussed earlier, this interface allows the developer to execute SQL stored procedures and pass IN and OUT parameters. Since the CallableStatement inherits the method from the Preparedstatement interface, all of the execute and setType methods are available. The following example will demonstrate the method of passing IN and OUT parameters to stored procedures and executing them.

import java.sql.*;import java.io.*;class caloric{ public static void main(String a[]) throws Exception {

Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");Connection con =

DriverManager.getConnection("jdbc:odbc:OraDsn","scott","tiger");CallableStatement c1 = con.prepareCall ("{call selectpro (?, ?)}");BufferedReader b = new BufferedReader(new

InputStreamReader(System.in));System.out.println("enter the no");int p1= Integer.parseInt(b.readLine());c1.setInt(1, p1);c1.registerOutParameter(2, Types.VARCHAR);c1.execute();


Page 95: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

String output =c1.getString(2);System.out.println("The name selected for the given number is



To run the program given above follow the steps given below:

Step 1: create or replace procedureselectpro (num in number, nam out varchar2 )isbeginselect name into nam from stud where no=num;end;

Step 2: Create a DSN(data source name)

Step 3: Compile the program using javac

Step 4: Run the program using java

Step 5: In the command promptness pass the empno. You will get the corresponding deptno

The output is as shown in Figure 7.12.

Fig. 7.12Output of the program

In the above program after initializing and loading the driver, the method prepareCall() of the Connection interface has been invoked to create the object of CallableStatement. The stored SQL procedure is passed as an argument to the prepareCall() method. It is parameterized using question marks in the same manner as that discussed for the PreparedStatement interface.

7.7.2 Using Type 2 Driver (The Native Library-to-Java Driver)

Before executing JDBC codes through Type 2 and Type 4, you must copy one of the two files called clsses81.zip and classes101.zip to the folder from where you are running the codes and set the classpath to that folder. These files are present inside the folder Oracle\Ora8i\jbdc\lib.

While creating the codes for Type 2 and Type 4 drivers, except the first two all the steps are same. Here you have to load and register the driver by specifying the classname oracle.jdbc.driver.OracleDriver where the specification of both Type 2 and Type 4 drivers are available. Secondly, you have to specify the driver name, which is passed as an argument with the getConnection() method.


Page 96: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

The code given below demonstrates the usage of the Native Library-to-Java Driver: In this code we are creating a new table, inserting a record it and finally displaying the record.

import java.sql.*; class orasql {

public static void main(String ar[]) {

try { DriverManager.registerDriver(new

oracle.jdbc.driver.OracleDriver()); Connection con = DriverManager.getConnection ("jdbc:oracle:oci8:@","scott","tiger"); Statement st=con.createStatement(); ResultSet rs=st.executeQuery("Select * from dept"); while(rs.next()) {

System.out.println(rs.getInt(1)+" : "+rs.getString(2)+" : "+rs.getString(3));

} }catch(Exception e) {e.printStackTrace(); }

} }

7.7.3 Using Type 4 Driver (The Native Protocol Driver)

The code given below demonstrates the usage of Native Protocol Driver. The following code displays all the name of the employees from the table emp.

import java.sql.*;class sqldemo1{ public static void main(String a[] ) throws Exception {

int StNo;String StName;Connection Conn;Statement Stmt;ResultSet rs;//Initialize and load the JDBC-ODBC driver.DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());// To get a database connectionConn


//To create a statement object to execute the SQL statementStmt = Conn.createStatement();//Sends the SQL statement to the DBMS and executivers = Stmt.executeQuery("select empno, ename from emp");//Processing the resultsSystem.out.println("Empno "+" Name ");while(rs.next()) {

StNo = rs.getInt(1); StName = rs.getString(2);

System.out.println(StNo+"\t"+StName); }


Page 97: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================


7.8 The ResultSetMetaData Interface

The java.sq1 package contains two MetaData interfaces, the DatabaseMetaData and the ResultSetMetaData interface. The DatabaseMetaData interface is used to obtain information about a database such as a list of all tables in the database, system functions, keywords, database product name, and the name of the JDBC driver supported by the database. The ResultSetMetaData interface is used to obtain information about the columns stored in a ResultSet object such as the datatype, the column heading, and the properties of each column. The following table explains some of the methods of the ResultSetMetaData interface.

Method Descriptionint getColumnCount ( ) Returns the number of columns stored

in a ResultSet objectString getColumnName (int column_number)

Returns the column name of the specified column

String getColumnTypeName (int column_number)

Returns the database specific datatype of the specified column.

You use the getMetaData ( ) method of the ResultSet class to obtain a reference to the ResultSetMetaData object of a particular result set.

Example:import java.sql.*;public class QueryApp{

public static void main(String a [ ]){

ResultSet result;String rowdata="";try{

Class.forName ("sun.jdbc.odbc.JdbcOdbcDriver");Connection con =

DriverManager.getConnection("jdbc:odbc:OraDsn", "scott", "tiger" );Statement stat=con.createStatement();result=stat.executeQuery("Select name,addr from stud");ResultSetMetaData rsmd=result.getMetaData( );int colCount=rsmd.getColumnCount ( );//Code to retrieve and display the column headings/* The String.trim ( ) method is used to remove leading andtrailing blanks in a string */for (int i=1; i<=colCount; i++){ rowdata=rowdata+" : "+rsmd.getColumnName(i).trim();}System.out.println (rowdata);System.out.println("---------------------------------------------------");rowdata=" ";while (result.next()){//Code to retrieves and display each record of the result set for (int i=1; i<=colCount; i++)



Page 98: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================

/* Retrieve the value present in the ith column of the current row

*/rowdata=rowdata+" :


System.out.println(rowdata);rowdata=" ";System.out.println("\n");

} }

catch (Exception e){ System.out.println ("Could not execute the query" +e);

} }}


Page 99: J2EE Spell

J2EE Servlets & JSP ===========================================================================================================================



Page 100: J2EE Spell



Application Assembler

A person that combines components and modules into larger deployable application units.

Application client

A first-tier client program that executes in its own Java Virtual Machine.

Application client container

A container that supports application clients and provides a federated view of the J2EE platform APIs.

Application client module

A software unit that consists of one or more classes and an application client deployment descriptor.

Application Component Provider

A vendor that provides the Java classes that implement components' methods, JSP page definitions, and any required deployment descriptors.


Application Programming Model. A programming model that defines how to use and combine the features of the J2EE platform to create solutions for common application domains in the enterprise.


Refers to an operation that is never interrupted or left in an incomplete state under any circumstance.


The process by which an entity proves to another entity that it is acting on behalf of a specific identity. The J2EE platform requires three types of authentication: basic, form-based, and mutual.


Refers to an operation that is never interrupted or left in an incomplete state under any circumstance.


Page 101: J2EE Spell


Basic authentication

When a Web server authenticates an entity with a user name and password obtained using the Web client's built-in authentication mechanism.


A reusable software component. Beans can be combined to create an application.

Bean-managed persistence

When the transfer of data between an entity bean instance's variables and the underlying resource manager is managed by the entity bean.

Bean-managed transaction

When an enterprise bean defines the boundaries of the transaction.

Bean-managed transaction

When an enterprise bean defines the boundaries of the transaction.

Business logic

The code that implements the functionality of an application. In the Enterprise JavaBeans model, this logic is implemented by the methods of an enterprise bean.

Business method

A method of an enterprise bean that implements the business logic or rules of an application.

Callback methods

Methods in a component called by the container to notify the component of important events in its life cycle.


A classpath is an environmental variable which tells the Java(TM) virtual machine* and Java technology-based applications (for example, the tools located in the JDK(TM) 1.1.X\bin directory) where to find the class libraries, including user-defined class libraries.


In the client/server model of communications, the client is a process that remotely accesses resources of a compute server, such as compute power and large memory capacity.



Page 102: J2EE Spell


Works together with the code attribute in the <APPLET> tag to give a complete specification of where to find the main applet class file: code specifies the name of the file, and codebase specifies the URL of the directory containing the file.


In a program, explanatory text that is ignored by the compiler. In programs written in the Java(TM) programming language, comments are delimited using // or /*...*/.


The point in a transaction when all updates to any resources involved in the transaction are made permanent.


An application-level software unit supported by a container. Components are configurable at deployment time. The J2EE platform defines four types of components: enterprise beans, Web components, applets, and application clients.

Component contract

The contract between a component and its container. The contract includes: life cycle management of the component, a context interface that the instance uses to obtain various information and services from its container, and a list of services that every container must provide for its components.

Component environment

A set of requirements defined by the Application Component Provider required to be available to a J2EE component in its naming environment. The environment entries are declaratively specified in the component's deployment descriptor. Each component names and accesses its environment configuration values using the java:comp/env JNDI context. These values can be objects a component is dependent on, such as a JDBC DataSource or a simple value such as a tax rate.

Container-managed persistence

When transfer of data between an entity bean's variables and the underlying resource manager is managed by the enterprise bean's container.

Container-managed transaction

When an EJB container defines the boundaries of a transaction. An entity bean must use container-managed transactions.

Context attribute

An object bound into the context associated with a servlet.

Conversational state


Page 103: J2EE Spell


The field values of a session bean plus the transitive closure of the objects reachable from the bean's fields. The transitive closure of a bean is defined in terms of the serialization protocol for the Java programming language, that is, the fields that would be stored by serializing the bean instance.


A person who installs modules and J2EE applications into an operational environment.


The process whereby software is installed into an operational environment.

Deployment descriptor

An XML file provided with each module and application that describes how they should be deployed. The deployment descriptor directs a deployment tool to deploy a module or application with specific container options and describes specific configuration requirements that a deployer must resolve.


Refers to a class, interface, constructor, method or field that is no longer recommended, and may cease to exist in a future version.

EJB container

A container that implements the EJB component contracts of the J2EE architecture. This contract specifies a runtime environment for enterprise beans that includes security, concurrency, life cycle management, transaction, deployment, and other services. An EJB container is provided by an EJB or J2EE server.

EJB Container Provider

A vendor that supplies an EJB container.

EJB context

An object that allows an enterprise bean to invoke services provided by the container and to obtain the information about the caller of a client-invoked method.

EJB home object

An object that provides the life cycle operations (create, remove, find) for an enterprise bean. The class for the EJB home object is generated by the container's deployment tools. The EJB home object implements the enterprise bean's home interface. The client references an EJB home object to perform life cycle operations on an EJB object. The client uses JNDI to locate an EJB home object.

EJB .jar file

A JAR archive that contains an EJB module.


Page 104: J2EE Spell


EJB module

A software unit that consists of one or more enterprise beans and an EJB deployment descriptor.

EJB object

An object whose class implements the enterprise bean's remote interface. A client never references an enterprise bean instance directly; a client always references an EJB object. The class of an EJB object is generated by the container's deployment tools.

EJB server

Software that provides services to an EJB container. For example, an EJB container typically relies on a transaction manager that is part of the EJB server to perform the two-phase commit across all the participating resource managers. The J2EE architecture assumes that an EJB container is hosted by an EJB server from the same vendor so does not specify the contract between these two entities. An EJB server may host one or more EJB containers.

EJB Server Provider

A vendor that supplies the EJB server.

EIS resource

An entity that provides EIS-specific functionality to its clients. Examples are: a record or set of records in a database system, a business objects in an ERP system, and a transaction program in a transaction processing system.

Enterprise Information System (EIS)

The applications that comprise an enterprise's existing system for handling company-wide information. These applications provide an information infrastructure for an enterprise. An EIS offers a well-defined set of services to its clients. These services are exposed to clients as local and/or remote interfaces. Examples of EISs include: an ERP system, a mainframe transaction processing system, and a legacy database system.

Enterprise Bean Provider

An application programmer who produces enterprise bean classes, remote and home interfaces, and deployment descriptor files, and packages them in an EJB .jar file.

Enterprise JavaBeans(TM) (EJB)

A component architecture for the development and deployment of object-oriented, distributed, enterprise-level applications. Applications written using the Enterprise JavaBeans architecture are scalable, transactional, and multi-user and secure.


Page 105: J2EE Spell


Entity bean

An enterprise bean that represents persistent data maintained in a database. An entity bean can manage its own persistence or it can delegate this function to its container. An entity bean is identified by a primary key. If the container in which an entity bean is hosted crashes, the entity bean, its primary key, and any remote references survive the crash.


HyperText Transfer Protocol. The Internet protocol, based on TCP/IP, used to fetch hypertext objects from remote hosts. See also

J2EE application

Any deployable unit of J2EE functionality. This can be a single module or a group of modules packaged into an .ear file with a J2EE application deployment descriptor. J2EE applications are typically engineered to be distributed across multiple computing tiers.

J2EE product

An implementation that conforms to the J2EE platform specification.

J2EE Product Provider

A vendor that supplies a J2EE product.

J2EE server

The runtime portion of a J2EE product. A J2EE server provides Web and/or EJB containers.

Java(TM) 2 Platform, Standard Edition (J2SE platform)

The core Java technology platform.

Java(TM) 2 Platform, Enterprise Edition (J2EE platform)

An environment for developing and deploying enterprise applications. The J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multi-tiered, Web-based applications.

Java(TM) 2 SDK, Enterprise Edition

Sun's implementation of the J2EE platform. This implementation provides an operational definition of the J2EE platform.



Page 106: J2EE Spell


A portable, platform-independent reusable component model.

Java Database Connectivity (JDBC(TM))

An industry standard for database-independent connectivity between the Java(TM) platform and a wide range of databases. The JDBC(TM) provides a call-level API for SQL-based database access.

Java(TM) Message Service (JMS)

An API for using enterprise-messaging systems such as IBM MQ Series, TIBCO Rendezvous, and so on.

Java Naming and Directory Interface(TM) (JNDI)

A set of APIs that assists with the interfacing to multiple naming and directory services.

Java(TM) Remote Method Invocation (RMI)

A distributed object model for Java(TM) program to Java program, in which the methods of remote objects written in the Java programming language can be invoked from other Java virtual machines*, possibly on different hosts.

Java(TM) Runtime Environment (JRE)

A subset of the Java Development Kit (JDK(TM)) for end-users and developers who want to redistribute the runtime environment alone. The Java runtime environment consists of the Java virtual machine*, the Java core classes, and supporting files.


A Web scripting language that is used in both browsers and Web servers. Like all scripting languages, it is used primarily to tie other components together or to accept user input.

JavaServer Pages(TM) (JSP)

An extensible Web technology that uses template data, custom elements, scripting languages, and server-side Java objects to return dynamic content to a client. Typically the template data is HTML or XML elements, and in many cases the client is a Web browser.

JSP action

A JSP element that can act on implicit objects and other server-side objects or can define new scripting variables. Actions follow the XML syntax for elements with a start tag, a body and an end tag; if the body is empty it can also use the empty tag syntax. The tag must use a prefix.

JSP action, standard


Page 107: J2EE Spell


An action that is defined in the JSP specification and is always available to a JSP file without being imported.

JSP action, custom

An action described in a portable manner by a tag library descriptor and a collection of Java classes and imported into a JSP page by a taglib directive.

JSP application

A stand-alone Web application written using the JavaServer Pages technology, including JSP files, servlets, HTML files, images, applets, and JavaBeans components.

JSP container

A container that provides the same services as a servlet container and an engine that interprets and processes JSP pages into a servlet.

JSP container, distributed

A JSP container that can run a Web application that is tagged as distributable and that executes across multiple Java virtual machines running on the same host or on different hosts.

JSP declaration

A JSP scripting element that declares methods, variables, or both in a JSP file.

JSP directive

A JSP element that gives an instruction to the JSP container and is interpreted at translation time.

JSP element

A portion of a JSP page that is recognized by a JSP translator. An element can be a directive, an action, or a scripting element.

JSP expression

A scripting element that contains a valid scripting language expression that is evaluated, converted to a String, and placed into the implicit out object.

JSP file

A file named with a .jsp extension that a developer authors using standard HTML tags, core JSP tags, custom JSP tags, and scripting language statements in order to display dynamic pages in a Web browser.

JSP page


Page 108: J2EE Spell


A text-based document using fixed template data and JSP elements that describe how to process a request to create a response.

JSP scripting element

A JSP declaration, scriptlet, or expression, whose tag syntax is defined by the JSP specification, and who’s content is written according to the scripting language used in the JSP page. The JSP specification describes the syntax and semantics for the case where the language page attribute is "java".

JSP scriptlet

A JSP scripting element containing any code fragment that is valid in the scripting language used in the JSP page. The JSP specification describes what is a valid scriptlet for the case where the language page attribute is "java".

JSP tag

A piece of text between a left angle bracket and a right angle bracket that is used in a JSP file as part of a JSP element. The tag is distinguishable as markup, as opposed to data, because it is surrounded by angle brackets.

JSP tag library

A collection of tags identifying custom actions described via a tag library descriptor and Java classes. A portable Java class library that has a unique URI and that defines custom tags that perform specialized tasks. A JSP tag library can be imported into any JSP file and used with various scripting languages.

Java Web Server(TM)

The easy-to-use, extensible, easy-to-administer, secure, platform-independent solution to speed and simplify the deployment and management of your Internet and Intranet Web sites. It provides immediate productivity for robust, full-featured, Java technology-based server applications.


A former business unit of Sun Microsystems, Inc., currently known as Sun Microsystems, Inc., Java Software division.


The process of transferring an enterprise bean from memory to secondary storage.


The protocol for transferring the state of an entity bean between its instance variables and an underlying database.

Primary key

An object that uniquely identifies an entity bean within a home.



Page 109: J2EE Spell


A Java program that extends the functionality of a Web server, generating dynamic content and interacting with Web clients using a request-response paradigm.

Servlet container

A container that provides the network services over which requests and responses are sent, decodes requests, and formats responses. All servlet containers must support HTTP as a protocol for requests and responses, but may also support additional request-response protocols such as HTTPS.

Servlet container, distributed

A servlet container that can run a Web application that is tagged as distributable and that executes across multiple Java virtual machines running on the same host or on different hosts.

Servlet context

An object that contains a servlet's view of the Web application within which the servlet is running. Using the context, a servlet can log events, obtain URL references to resources, and set and store attributes that other servlets in the context can use.

Servlet mapping

Defines an association between a URL pattern and a servlet. The mapping is used to map requests to servlets. If the container handling the request is a JSP container, a URL containing a .jsp extension is implicitly mapped.


An object used by a servlet to track a user's interaction with a Web application across multiple HTTP requests.

Session bean

An enterprise bean that is created by a client and that usually exists only for the duration of a single client/server session. A session bean performs operations, such as calculations or accessing a database, for the client. While a session bean may be transactional, it is not recoverable should a system crash occur. Session bean objects can be either stateless or they can maintain conversational state across methods and transactions. If they do maintain state, then the EJB container manages this state if the object must be removed from memory. However, the session bean object itself must manage its own persistent data.


Standardized Generalized Markup Language. An ISO/ANSI/ECMA standard that specifies a way to annotate text documents with information about types of sections of a document.

Smart Web Services

Smart Web Services extend the basic concept of web services by adding the dimension of user context, and are able to modify their operation to track along


Page 110: J2EE Spell


with changes in a user's current situation. This includes the classic "who, what, when, where, why" descriptors that come together to define a user's context at a any given moment.

Stateful session bean

A session bean with a conversational state.

Stateless session bean

A session bean with no conversational state. All instances of a stateless session bean are identical.

Thin Client

A system that runs a very light operating system with no local system administration and executes applications delivered over the network.


Uniform Resource Identifier. A compact string of characters for identifying an abstract or physical resource. A URI is either a URL or a URN. URLs and URNs are concrete entities that actually exist; A URI is an abstract superclass.


Uniform Resource Locator. A standard for writing a text reference to an arbitrary piece of data in the WWW. A URL looks like "protocol://host/localinfo" where protocol specifies a protocol to use to fetch the object (like HTTP or FTP), host specifies the Internet name of the host on which to find it, and localinfo is a string (often a file name) passed to the protocol handler on the remote host.

URL path

The URL passed by a HTTP request to invoke a servlet. The URL consists of the Context Path + Servlet Path + PathInfo, where Context Path is the path prefix associated with a servlet context that this servlet is a part of. If this context is the default context rooted at the base of the web server's URL namespace, the path prefix will be an empty string. Otherwise, the path prefix starts with a / character but does not end with a / character. Servlet Path is the path section that directly corresponds to the mapping, which activated this request. This path starts with a / character. PathInfo is the part of the request path that is not part of the Context Path or the Servlet Path.

Web application, distributable

A Web application that uses J2EE technology written so that it can be deployed in a Web container distributed across multiple Java virtual machines running on the same host or different hosts. The deployment descriptor for such an application uses the distributable element.

Web component

A component that provides services in response to requests; either a servlet or a JSP page.


Page 111: J2EE Spell


Web container

A container that implements the Web component contracts of the J2EE architecture. This contract specifies a runtime environment for Web components that includes security, concurrency, life cycle management, transaction, deployment, and other services. A container that provides the same services as a JSP container and federated view of the J2EE platform APIs. A Web container is provided by a Web or J2EE server.


Extensible Markup Language. A markup language that allows you to define the tags (markup) needed to identify the data and text in XML documents. J2EE deployment descriptors are expressed in XML.


Page 112: J2EE Spell




Page 113: J2EE Spell

Appendix A================================================================================================================================

Appendix A

Common HTTP Status Codes

OK 200 The request was fulfilled.

Bad request 400 The request had bad syntax or was inherently impossible to be satisfied.

Unauthorized 401 The parameter to this message gives a specification of authorization schemes which are acceptable. The client should retry the request with a suitable Authorization header.

PaymentRequired 402 The parameter to this message gives a specification of charging schemes acceptable. The client may retry the request with a suitable ChargeTo header.

Forbidden 403 The request is for something forbidden. Authorization will not help.

Not found 404 The server has not found anything matching the URI given

Internal Error 500 The server encountered an unexpected condition which prevented it from fulfilling the request.

Not implemented 501 The server does not support the facility required.

Service temporarily overloaded 502 The server cannot process the request due to a high load (whether HTTP servicing or other requests). The implication is that this is a temporary condition which maybe alleviated at other times.

Gateway timeout 503 (TO BE DISCUSSED) This is equivalent to Internal Error 500, but in the case of a server which is in turn accessing some other service, this indicates that the response from the other service did not return within a time that the gateway was prepared to wait. As from the point of view of the client and the HTTP transaction the other service is hidden within the server, this maybe treated identically to Internal error 500, but has more diagnostic value.


Page 114: J2EE Spell

Appendix B================================================================================================================================

Appendix B


Q: What is a output comment? A: A comment that is sent to the client in the viewable page source. The JSP engine handles an output comment as uninterpreted HTML text, returning the comment in the HTML output sent to the client. You can see the comment by viewing the page source from your Web browser.

JSP Syntax<!-- comment [ <%= expression %> ] -->

Example 1<!-- This is a comment sent to client on<%= (new java.util.Date()).toLocaleString() %>-->

Displays in the page source:<!-- This is a comment sent to client on January 24, 2004 -->

Q: What is a Hidden Comment? A: A comments that documents the JSP page but is not sent to the client. The JSP engine ignores a hidden comment, and does not process any code within hidden comment tags. A hidden comment is not sent to the client, either in the displayed JSP page or the HTML page source. The hidden comment is useful when you want to hide or "comment out" part of your JSP page. You can use any characters in the body of the comment except the closing --%> combination. If you need to use --%> in your comment, you can escape it by typing --%\>. JSP Syntax<%-- comment --%>

Q: What are implicit objects? List them? A: Certain objects that are available for the use in JSP documents without being declared first. These objects are parsed by the JSP engine and inserted into the generated servlet. The implicit objects re listed belowrequest response pageContext session application out config page exception Q: Difference between forward and sendRedirect?


Page 115: J2EE Spell

Appendix B================================================================================================================================

A: When you invoke a forward request, the request is sent to another resource on the server, without the client being informed that a different resource is going to process the request. This process occurs completely with in the web container. When a sendRedirect method is invoked, it causes the web container to return to the browser indicating that a new URL should be requested. Because the browser issues a completely new request any object that are stored as request attributes before the redirect occurs will be lost. This extra round trip a redirect is slower than forward.

Q: Explain the life-cycle methods in JSP? A: The generated servlet class for a JSP page implements the HttpJspPage interface of the javax.servlet.jsp package. The HttpJspPage interface extends the JspPage interface which intern extends the Servlet interface of the javax.servlet package. the generated servlet class thus implements all the methods of the these three interfaces. The JspPage interface declares only two methods - spinet() and jspDestroy() that must be implemented by all JSP pages regardless of the client-server protocol. However the JSP specification has provided the HttpJspPage interface specifically for the JSP pages serving HTTP requests. This interface declares one method _jspService(). The jspInit()- The container calls the jspInit() to initialize the servlet instance. It is called before any other method, and is called only once for a servlet instance.The _jspservice()- The container calls the _jspservice() for each request, passing it the request and the response objects.The jspDestroy()- The container calls this when it decides take the instance out of service. It is the last method called n the servlet instance. Q: What is the difference between the getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface and javax.servlet.ServletContext interface? A: The getRequestDispatcher(String path) method of javax.servlet.ServletRequest interface accepts parameter the path to the resource to be included or forwarded to, which can be relative to the request of the calling servlet. If the path begins with a "/" it is interpreted as relative to the current context root.

The getRequestDispatcher(String path) method of javax.servlet.ServletContext interface cannot accepts relative paths. All path must start with a "/" and are interpreted as relative to current context root.

Q: Explain the directory structure of a web application. A: The directory structure of a web application consists of two parts. A private directory called WEB-INFA public resource directory which contains public resource folder.

WEB-INF folder consists of 1. web.xml2. classes directory3. lib directory

Q: Explain ServletContext.


Page 116: J2EE Spell

Appendix B================================================================================================================================

A: ServletContext interface is a window for a servlet to view it's environment. A servlet can use this interface to get information such as initialization parameters for the web application or servlet container's version. Every web application has one and only one ServletContext and is accessible to all active resource of that application.

Q: What is preinitialization of a servlet? A: A container doesn’t initialize the servlets ass soon as it starts up, it initializes a servlet when it receives a request for that servlet first time. This is called lazy loading. The servlet specification defines the <load-on-startup> element, which can be specified in the deployment descriptor to make the servlet container load and initialize the servlet as soon as it starts up. The process of loading a servlet before any request comes in is called preloading or preinitializing a servlet.

Q: What is the difference between Difference between doGet() and doPost()? A: A doGet() method is limited with 2k of data to be sent, and doPost() method doesn't have this limitation. A request string for doGet() looks like the following: http://www.allapplabs.com/svt1?p1=v1&p2=v2&...&pN=vN doPost() method call doesn't need a long text tail after a servlet name in a request. All parameters are stored in a request itself, not in a request string, and it's impossible to guess the data transmitted to a servlet only looking at a request string.

Q: What is the difference between HttpServlet and GenericServlet? A: A GenericServlet has a service() method aimed to handle requests. HttpServlet extends GenericServlet and adds support for doGet(), doPost(), doHead() methods (HTTP 1.0) plus doPut(), doOptions(), doDelete(), doTrace() methods (HTTP 1.1). Both these classes are abstract.


Page 117: J2EE Spell

Appendix C================================================================================================================================

Appendix C

MVC Architecture

1.What are Design Patterns?

As you design and build different applications, you continually come across the same or very similar problem domains. This leads you to find a new solution for the similar problem each time. To save time and effort, it would be ideal if there was a repository which captured such common problem domains and proven solutions.

In the simplest term, such a common solution is a design pattern. The repository or place of reference that contains these patterns is a design pattern catalog.

A design pattern describes a proven solution, from experienced hands, for a recurring design problem. These solutions are very generic. They are described in well-defined Pattern Templates, with the most popular template defined by the Gang of Four.

The pattern template usually includes a name that gives an idea as to what that pattern is about, followed by where the pattern is applicable, the motivation, the issues in implementation, and so on. Apart from describing the problem and illustrating the solution, the pattern also explains the implementation issues involved and consequences, if any, of using the pattern.

Use of such patterns makes the design of an application transparent. These patterns have been used successfully by developers in their respective fields, and therefore, the pros and cons of the pattern (as well as implementation issues) are known beforehand. All design patterns are reusable and can be adapted to particular contexts. This gives you flexibility. The use of design patterns related to J2EE applications gives the added advantage of showing solutions in terms of J2EE platform technologies.

2.Design Patterns For Building Flexible and Maintainable J2EE Applications

Multi-tiered J2EE applications consist of a number different views and components in the middle tier, possibly distributed. The following sections of this article suggest some design patterns that can help you keep typical J2EE applications extensible, flexible, and maintainable. Instead of discussing some abstract scenarios, this articles takes an imaginary sample application and tries to give you an understanding of these patterns in the context of this sample application. Once you know the sample application it is easier to extend the use of these patterns to other application scenarios.

Take the case of an enterprise application for financial services over the web. Visitors to this site can browse through the list of services, create accounts, place orders for the products made available by the financial service, and so on. Also assume that this application allows existing customers to change their account details and profile, make use of services, and so on. Typically this kind of application has multiple views or screens which users click through to search for lists of services, access profiles, use the services, and to get other information. The business logic represents the user's account, profile, the catalog of services, ordering for services, and so on, as


Page 118: J2EE Spell

Appendix C================================================================================================================================

separate entities in the form of Enterprise JavaBeans (EJB). With this sample application in mind, look at some recurring problems and see how you can use specific patterns to build a flexible and maintainable application.


Problem Domain

All would be well if you were building this enterprise application for a single type of client. If that were the case, we could simply mix the data access / data modifying logic with the logic for the various client views. But with the advent of the completely interconnected and wireless world, there are client devices ranging from PDAs to cell phones to a browser on a powerful desktop, in addition to other types of traditional clients. In this scenario, solving this problem by mixing data access with views is problematic because

← You must develop different versions of the same application to suit each type of client needs support

← Since the code for views and that for data access/modification is intertwined, the code for the data access/modification is duplicated everywhere, thereby making the application almost unmaintainable

← The development life cycle is extended unnecessarily.

Suggested Solution

In finding a solution for this problem, take note that:

← Regardless of the client type, the data being accessed and displayed comes from the same enterprise data source.

← All clients must be able to modify the data source. ← Modifying either a type of client or data accessing / modifying logic should not

affect the other components of the application.

You need a solution that lets you develop loosely-coupled applications. The Model-View-Controller (MVC) architecture is the suggested solution. MVC has been used very effectively in GUI-type applications. By applying the MVC architecture to a J2EE application, you can separate the data access logic from the data presentation logic. You can also build a flexible and easily extensible controller that controls the whole flow of the application. The figure below depicts the MVC architecture.


Page 119: J2EE Spell

Appendix C================================================================================================================================

The MVC architecture can be mapped to multi-tiered enterprise J2EE applications as follows:

← All enterprise data and the business logic to process the data can be represented in the MODEL.

← The VIEW can access the data through the model and decide on how to present them to the client. The VIEW must ensure that the presentation changes as and when the MODEL changes.

← The CONTROLLER can interact with the view and convert the client actions into actions that are understood and performed by the MODEL. The CONTROLLER also decides on the next view to be presented depending on the last client action and results of the corresponding MODEL action(s).

Applying the above logic to the sample financial application, you build the application as follows:

← The business logic of the application is represented by EJBs that form the MODEL of MVC architecture. The MODEL responds to requests from CONTROLLER to access / modify the data it represents.

← The various screens of the application forms the VIEW of the MVC architecture. The VIEW updates itself when the MODEL changes.

← The CONTROLLER of the application is a set of objects that receive the user actions, convert them into requests understood by the model, and decide on the next screen to be displayed once the model completes the processing request

It is very difficult to fully showcase the MVC architecture in the form of a small example code. The Java Pet Store Demo application from the J2EE BluePrints Program is a good example of a complete J2EE application that is based on the MVC architecture.

Points to Note


Page 120: J2EE Spell

Appendix C================================================================================================================================

Here are some points to note:

← MVC architecture is suitable for a highly interactive system that requires extensibility, maintainability, and multiple user views.

← MVC decouples presentation, user interaction, and system model. ← Presenting multiple views for multiple data sets is made easy because of the

decoupling. This also makes it much easier to enable support for new types of clients.

← Code duplication is minimized by using this architecture. ← By separating the presentation from model and overall application flow, this

architecture enables division of developer responsibilities, and thereby, produces faster time to market.


Page 121: J2EE Spell



Book References:

Title Author Publication EditionProfessional Java Server Programming

Subramanyam Allamaraju APress J2EE 1.3 Edition

Expert One-on-One J2EE Design and Development

Rod JohnsonWiley Publishing Inc. 2003

Core J2EE Patterns: Best Practices and Design Strategies

Deepak Alur, Dan Malks, John Crupi Sun Press Second Edition

Enterprise JavaBeans

Richard Monson-Haefel, Bill Burke, Sacha Labourey

O’Reilly Fourth Edtion

Head First Servlets & JSP

Bryan Basham, Kathy Sierra , Bert Bates

O’Reilly 2004

Online References:

URL Description

http://java.sun.comThe J2EE home website, containing the most current information on the J2EE Platform

http://java.sun.com/j2ee/docs.html The complete J2EE API.www.experts-exchange.com J2EE Interview questions.http://bea.com Weblogic Home Websitewww.ejbtut.com EJB Tutorial


Page 122: J2EE Spell


Lab Works


Page 123: J2EE Spell


Servlet & JSP Programs


1. JDBC:import java.lang.*;import javax.sql.*;import java.sql.*;

class db1{

public static void main(String args[]) throws Exception{

int no;String name,place;

Class.forName("com.mysql.jdbc.Driver");System.out.println("Driver has loaded");Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/prem","root","admin");System.out.println("Connection Established");Statement st=con.createStatement();ResultSet rs=st.executeQuery("select * from emp1");

System.out.println("\t\t NO \t\t NAME \t\t PLACE");


no=rs.getInt(1);name=rs.getString(2);place=rs.getString(3);System.out.println("\t\t "+no+"\t\t "+name+"\t\t "+place);



2.Simple Servlet Program:

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class servlet1 extends HttpServlet{

public void doGet(HttpServletRequest req,HttpServletResponse res) {

try{PrintWriter out=res.getWriter();res.setContentType("text/html");out.println("***WELCOME***");}

catch(Exception e){}


Page 124: J2EE Spell



3.JDBC & Servlets:

import javax.servlet.*;import javax.servlet.http.*;import java.sql.*;import java.io.*;

public class servlet3 extends HttpServlet{

public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException,IOException{

try{int no;String name,place;PrintWriter out=res.getWriter();res.setContentType("text/html");Class.forName("com.mysql.jdbc.Driver");Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/prem","root","admin");Statement st=con.createStatement();ResultSet rs=st.executeQuery("select * from emp1");out.println("CONTENTS IN THE TABLE<br>");out.println("NO NAME PLACE<br>");




catch(Exception e){}}


4. Simple login page:



Page 125: J2EE Spell



<form action="login" method="get"> USERNAME <input type="text" name="usname"><br><br> PASSWORD <input type="password" name="psword"><br><br>

<input type="submit" value="Submit"> <input type="reset" value="Reset"></form></BODY></HTML>


import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class login extends HttpServlet{

public void doGet(HttpServletRequest req,HttpServletResponse res) {

try{PrintWriter out=res.getWriter();res.setContentType("text/html");String s1=req.getParameter("usname");String s2=req.getParameter("psword");out.println("Welcome to Home Page <br>");out.println("Ur user name is : "+s1);}catch(Exception e){}



import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class sessioncount extends HttpServlet {

public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException,IOException{

try{res.setContentType("text/html");PrintWriter pw=res.getWriter();HttpSession hs=req.getSession(true);if(hs.getAttribute("counter")==null)


Page 126: J2EE Spell


{hs.setAttribute("counter", new Integer(1));


int c=((Integer) hs.getAttribute("counter")).intValue()+1;hs.setAttribute("counter", new Integer(c));

}pw.println("<h1> USER VIEWERS : " +hs.getAttribute("counter"));}catch(Exception e) {}


6.Cookies:import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class cookies extends HttpServlet {

public void service(HttpServletRequest req, HttpServletResponse res) throws ServletException,IOException{

try{res.setContentType("text/html");PrintWriter pw=res.getWriter();Cookie c1=new Cookie("Emp no","001");Cookie c2=new Cookie("Emp name","prem");Cookie c3=new Cookie("User id","pp");



pw.println("<h2> Response sets all the cookies");}catch (Exception e) {}


7. Servlet Inter-Communication (Request Dispatcher):

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class servletcomm_rd extends HttpServlet


Page 127: J2EE Spell


{RequestDispatcher rd;public void service(HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException{

res.setContentType("text/plain");PrintWriter p=res.getWriter();String name=req.getParameter("name");String psword=req.getParameter("psword");







8. Servlet Inter-Communication (Send Redirect):

import javax.servlet.*;import javax.servlet.http.*;import java.io.*;import java.lang.*;

public class servletcomm_srd extends HttpServlet{

public void service(HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException{

res.setContentType("text/plain");PrintWriter p=res.getWriter();String name=req.getParameter("name");String psword=req.getParameter("psword");




} )JSP

9. JSP Directive:



Page 128: J2EE Spell


<TITLE> New Document </TITLE></HEAD><BODY>

<%@ page import="java.util.Date" %><%@ include file="included.html"%>Current date is <%= new Date() %>


10. Jsp Scripting: <HTML><%

int c=3;

public String disp(String s){

return "WELCOME " + s + "..!!";}


<h1><CENTER> METHOD DECLERATION </CENTER></H1><p> The value of count is : <%=c %></p><p> HELLO <%= disp("FRIENDS") %></p>


11. Jsp & Servlets:



<form action="login" method="get"> USERNAME <input type="text" name="usname"><br><br> PASSWORD <input type="password" name="psword"><br><br>

<input type="submit" value="Submit"> <input type="reset" value="Reset"></form></BODY></HTML>


import javax.servlet.*;import javax.servlet.http.*;import java.io.*;

public class login extends HttpServlet{

public void doGet(HttpServletRequest req,HttpServletResponse res)


Page 129: J2EE Spell



{PrintWriter out=res.getWriter();res.setContentType("text/html");String s1=req.getParameter("usname");String s2=req.getParameter("psword");out.println("Welcome to Home Page <br>");out.println("Ur user name is : "+s1);}catch(Exception e){}


12. Jsp, Servlets & JDBC:



<form action="login" method="get"> USERNAME <input type="text" name="name"><br><br> PASSWORD <input type="password" name="psword"><br><br>

<input type="submit" name="submit"> <input type="reset" name="reset"></form></BODY></HTML>


import javax.servlet.jsp.*;import javax.servlet.*;import javax.servlet.http.*;import java.io.*;import java.sql.*;

public class loginservlet extends HttpServlet{

RequestDispatcher rd;public void service(HttpServletRequest req,HttpServletResponse res) throws ServletException, IOException{

try{Class.forName("com.mysql.jdbc.Driver");Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/prem","root","admin");Statement st=con.createStatement();ResultSet rs=st.executeQuery("select * from login");


Page 130: J2EE Spell


String name1,psword;int c=0;res.setContentType("text/plain");PrintWriter p=res.getWriter();String n=req.getParameter("name");String pw=req.getParameter("pass");HttpSession hs=req.getSession();






}}catch(Exception e) {}



<%@page language="java" %>

<%String name=(String) session.getAttribute("n");out.println(" <h1><b><center> WELCOME !!

</h1></b></center><br></br>");out.println(" <h3><i> USER NAME IS : " + name+ "</h3></i>");




Page 131: J2EE Spell



<%@page language="java" %>

<%out.println("YOU ARE NOT A VALID USER");




Page 132: J2EE Spell



Page 133: J2EE Spell



Page 134: J2EE Spell