BUY THIS BOOK

Safari Books Online

What is this?

Looking to Reprint this content?

Envelope Tell a friend

Programming Jakarta Struts
Programming Jakarta Struts By Chuck Cavaness
November 2002
Pages: 462

Cover | Table of Contents | Colophon

Table of Contents

Chapter 1: Introduction
Content preview·Buy reprint rights for this chapter
The Struts open source framework was created to make it easier for developers to build web applications based on the Java Servlet and JavaServer Pages (JSP) technologies. Like a building, a web application must have a solid foundation from which the rest of the structure can grow. The Struts framework provides developers with a unified infrastructure upon which Internet applications can be based. Using Struts as the foundation allows developers to concentrate on building the business application rather than on the infrastructure.
The Struts framework was created by Craig R. McClanahan and donated to the Apache Software Foundation (ASF) in 2000. The project now has several committers from around the world, and many developers are contributing to the overall good of the framework. The Struts framework is one of many well-known and successful Apache Jakarta projects. Others include Ant, log4j, and Tomcat. The overall mission of the Jakarta project is to provide commercial-quality server solutions, based on the Java platform, in an open and cooperative fashion.
No book on web technology would be complete without a brief look at how the World Wide Web (WWW) has become as popular as it is today. The Web has come a long way since the days when the first hypertext documents were sent over the Internet. In 1989, when the physicists at the CERN laboratory proposed the idea of sharing research information between researchers using hypertext documents, they had no idea how big the Web would grow or how essential it would become to daily life for much of the industrialized world. The Web is now an accepted part of our vernacular.
It took a while for the benefits of using the Web to become clear to others outside of CERN, but as we all know, it eventually erupted into what we use today. From its beginnings, the Web was designed for dealing with static documents, but it was a natural progression to want the ability to generate document content dynamically. The Common Gateway Interface (CGI) was created to do that very thing. CGI is a standard that allows web servers to interact with external applications in such a way that hypertext pages no longer have to be static. A CGI program can retrieve results from a database and insert those results as a table in a hypertext document. Likewise, data entered into a hypertext page can be inserted into the database. This technology opened up infinite possibilities and, in fact, started the Internet craze of the mid-1990s and today.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
A Brief History of the Web
Content preview·Buy reprint rights for this chapter
No book on web technology would be complete without a brief look at how the World Wide Web (WWW) has become as popular as it is today. The Web has come a long way since the days when the first hypertext documents were sent over the Internet. In 1989, when the physicists at the CERN laboratory proposed the idea of sharing research information between researchers using hypertext documents, they had no idea how big the Web would grow or how essential it would become to daily life for much of the industrialized world. The Web is now an accepted part of our vernacular.
It took a while for the benefits of using the Web to become clear to others outside of CERN, but as we all know, it eventually erupted into what we use today. From its beginnings, the Web was designed for dealing with static documents, but it was a natural progression to want the ability to generate document content dynamically. The Common Gateway Interface (CGI) was created to do that very thing. CGI is a standard that allows web servers to interact with external applications in such a way that hypertext pages no longer have to be static. A CGI program can retrieve results from a database and insert those results as a table in a hypertext document. Likewise, data entered into a hypertext page can be inserted into the database. This technology opened up infinite possibilities and, in fact, started the Internet craze of the mid-1990s and today.
Although CGI applications are very good at what they do, there are some serious limitations to this approach. For one thing, CGI applications are very resource-intensive. A new operating system (OS) heavyweight process is created to handle every request that comes from a browser. Once the CGI script is finished executing, the process has to be reclaimed by the OS. This constant starting and stopping of heavyweight processes is terribly inefficient. You can imagine how bad the response time might be if hundreds of concurrent users were making requests to the same web application. Another major limitation of CGI is that it's difficult to link to other stages of request processing, because it is running in a separate process from the web server. This makes it difficult to handle things such as authorization, workflow, and logging.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
What Are Java Servlets?
Content preview·Buy reprint rights for this chapter
Java servlets have become the mainstay for extending and enhancing web applications using the Java platform. They provide a component-based, platform-independent method for building web applications. Servlets don't suffer from the same performance limitations that standard CGI applications incur. Servlets are more efficient than the standard CGI threading model because they create a single heavyweight process and allow each user request to use a much more lightweight thread, which is maintained by the Java Virtual Machine (JVM), to fulfill the request. Multiple user requests can be threaded through the same instance of a servlet. A servlet is mapped to one or more uniform resource locators (URLs), and when the server receives a request to one of the servlet URLs, the service method in the servlet is invoked and it responds. Because each user request is associated with a separate thread, multiple threads or users can invoke the service method at the same time. This multithreaded nature of servlets is one of the main reasons that they are more scalable than standard CGI applications. Also, because servlets are written in Java, they are not proprietary to a platform or OS.
Another significant advantage of being written in the Java language is that servlets are able to exploit the entire suite of Java application programming interfaces (APIs), including Java DataBase Connectivity™ (JDBC) and Enterprise JavaBeans (EJB). This was one of the factors in servlets becoming part of the mainstream so quickly; there already was a rich Java library in place for them to leverage.
Servlets are not executed directly by a web server. They require a servlet container, sometimes referred to as a servlet engine, to host the servlet. This servlet container is loosely coupled to a particular instance of a web server, and together they cooperate to service requests. Figure 1-1 illustrates how a web server and servlet container cooperate to service a request from a web browser.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
JavaServer Pages
Content preview·Buy reprint rights for this chapter
The first thing to understand about JavaServer Pages is that it's a natural extension to the Java Servlet technology. In fact, after some preprocessing by a translator, JSP pages end up being nothing more than Java servlets. This is a point that many beginning developers have a hard time understanding. JSP pages are text documents that have a .jsp extension and contain a combination of static HTML and XML-like tags and scriptlets. The tags and scriptlets encapsulate the logic that generates the content for the pages. The .jsp files are preprocessed and turned into .java files. At this point, a Java compiler compiles the source and creates a .class file that can be executed by a servlet container.
The translator that turns the .jsp file into a .java file takes care of the tedious work of creating a Java servlet from the JSP page. Figure 1-2 illustrates how a JSP page is translated and compiled into a servlet.
Figure 1-2: A JSP page is translated and compiled into a Java servlet
JSP technology has become an extremely popular solution for building web applications using the Java platform. JSP offers several advantages over its competitors:
  • JSP is a specification, not a product. Developers are able to choose a "best of breed" approach.
  • JSP pages are compiled, not interpreted, which can lead to better performance.
  • JSP pages support both scripting and access to the full Java language and can be extended through the use of custom tags.
  • JSP pages share the Write Once, Run Anywhere™ characteristics of Java technology.
As mentioned in the previous section, one of the limitations of using hardcoded HTML inside of servlets is the problem of separating page design and application logic programming responsibilities. This separation is easier with JSP pages, because the HTML designers are free to create web pages with whatever tools they choose (many of today's popular tools are capable of working with JSP and custom tags). When they are comfortable with the page layout, the JSP developers can insert JSP scriptlets and custom tags and save the files with a
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
JSP Model 1 and Model 2 Architectures
Content preview·Buy reprint rights for this chapter
The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were the JSP Model 1 and Model 2 architectures. Although these terms are no longer used in the JSP specification, they still are widely used throughout the web tier development community.
The two JSP architectures differ in several key areas. The major difference is in how and by which component the processing of a request is handled. With the Model 1 architecture, the JSP page handles all of the processing of the request and is responsible for displaying the output to the client. This is illustrated in Figure 1-3.
Figure 1-3: JSP Model 1 architecture
Notice that there is no extra servlet involved in the process. The client request is sent directly to a JSP page, which may communicate with JavaBeans or other services, but ultimately the JSP page selects the next page for the client. The next view is determined based on either the JSP selected or parameters within the client's request.
In contrast, in the Model 2 architecture, the client request is first intercepted by a servlet, referred to as a controller servlet . This servlet handles the initial processing of the request and determines which JSP page to display next. This approach is illustrated in Figure 1-4.
Figure 1-4: JSP Model 2 architecture
As shown in the figure, a client never sends a request directly to a JSP page in the Model 2 architecture. This allows the servlet to perform front-end processing, including authentication and authorization, centralized logging, and help with internationalization. Once request processing has completed, the servlet directs the request to the appropriate JSP page. How the next page is determined varies widely across different applications. For example, in simpler applications, the next JSP page to display may be hardcoded in the servlet based on the request, parameters, and current application state. In more sophisticated web applications, a workflow/rules engine might be used.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Why Is Model-View-Controller So Important?
Content preview·Buy reprint rights for this chapter
The MVC architectural pattern is not directly related to web applications. In fact, it's quite common in Smalltalk applications, which generally have nothing to do with the Web.
As we saw in the previous section, the Model 2 approach is concerned with separating responsibilities in web applications. Allowing a JSP page to handle the responsibilities of receiving the request, executing some business logic, and then determining the next view to display can make for an unattractive JSP page, not to mention the maintenance and extensibility problems this entanglement causes. Application development and maintenance are much easier if the different components of a web application have clear and distinct responsibilities.
As an example, say you want to integrate security into your web site. Your first page, in this case, usually is a login screen that collects and validates the username and password. This page then directs the user to another screen that allows her to continue in a secure manner. However, as there is nothing to prevent the user from going directly to a page, each page (in a non-MVC world) needs to be aware of security. This can be accomplished by including a security check on every page, but that can be unwieldy, especially if there are some pages that need to be secure and some that do not. In the MVC world, the security is put inside the controller object. Because the interface to the customer is driven through the controller object, there is a single entry point and a single location for the security checks to be performed.
The MVC pattern is categorized as a design pattern in many software design books. Although there is much disagreement on the precise definition of the pattern, there are some fundamental ideas.
The MVC pattern has three key components:
Model
Responsible for the business domain state knowledge
View
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
What Is a Framework?
Content preview·Buy reprint rights for this chapter
I have been using the term framework in this chapter without having defined what exactly it is, or how it adds value in software development. In its simplest form, a framework is a set of classes and interfaces that cooperate to solve a specific type of software problem. A framework has the following characteristics:
  • A framework comprises multiple classes or components, each of which may provide an abstraction of some particular concept.
  • The framework defines how these abstractions work together to solve a problem.
  • Framework components are reusable.
  • A framework organizes patterns at a higher level.
A good framework should provide generic behavior that many different types of applications can make use of.
There are many interpretations of what constitutes a framework. Some might consider the classes and interfaces provided by the Java language a framework, but these are really a library. There's a subtle, but very important, difference between a software library and a framework. A software library contains functions or routines that your application can invoke. A framework, on the other hand, provides generic, cooperative components that your application extends to provide a particular set of functions. The places where the framework can be extended are known as extension points. A framework commonly is referred to as an "upside-down" library because of the alternate manner in which it operates. Figure 1-5 illustrates the subtle differences between frameworks and software libraries.
Figure 1-5: A framework and a library are not the same thing
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Creation of the Struts Framework
Content preview·Buy reprint rights for this chapter
The Struts framework was created by Craig R. McClanahan and donated to the ASF in 2000. Craig is deeply involved in the expert groups for the Servlet and JSP specifications and wrote a large portion of the Tomcat 4.0 implementation. He also speaks at various conferences, including JavaOne and ApacheCon.
Several committers have joined the Struts project, and even more developers have volunteered their time and effort to improve it and increase its value. As a result, the framework has gone through several beta releases and a few general availability (GA) releases, and although many new features have been added, the framework hasn't strayed far from its core ideas.
The Struts group always welcomes new participants. To become a contributor, it's recommended that you first join the Struts User mailing list. If you like what you see there, take a look at the Struts Developers mailing list. This is the best way to get started and become familiar with the direction of the project. You should read the mailing list guidelines, at http://jakarta.apache.org/site/mail.html, before joining. You can then join one or more of the Jakarta Project's mailing lists, including those for Struts, from the URL http://jakarta.apache.org/site/mail2.html.
The main project web site for Struts is located at http://jakarta.apache.org/struts/. For more information on downloading and installing Struts, see Appendix B.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Alternatives to Struts
Content preview·Buy reprint rights for this chapter
Before we get too far into our discussion of the Struts framework, this section will briefly introduce some alternatives to Struts. Because versions and features may change with each new release, you should conduct your own research. This list of alternatives is by no means exhaustive, but it will provide you with a launching pad. I could have saved this section for the end of the book, but I wanted to familiarize you with some other frameworks so that you can compare them with Struts as you work through this book.
Note that only solutions based on or around the Java platform are listed here. Microsoft also offers a competing technology based on Active Server Pages (ASP). Although the goal of ASP is similar to that of JSP, ASP and ASP+ are not discussed here—they're better left for a book on JSP and servlets. Furthermore, the Struts framework goes well beyond what is offered by JSP alone, and comparing ASP or other similar technologies to Struts wouldn't make sense.
At first, it might seem strange to present building your own framework as an alternative to using Struts. Why would you want to build frameworks from scratch, when they already exist in many different forms? The answer is the same reason that other open source or commercial products are developed. The available selection of products just might not be close enough to your desired framework, and it might be preferable to build it in-house.
The best advice I can give regarding building your own framework is to ask yourself several questions:
  1. Have I taken the time to inspect what's available and build a prototype using an available framework?
  2. What does my application need that doesn't exist in one of the available frameworks?
  3. Can I extend an existing framework to suit my needs or find what I need at another source and add it?
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 2: Inside the Web Tier
Content preview·Buy reprint rights for this chapter
This chapter discusses the relationship between the architectural tiers and their roles in an application. Special attention is given to the web tier, which allows an application to communicate and interoperate with clients over the Web. In particular, this chapter focuses on the physical and logical aspects of designing and using a web tier for your applications.
The Struts framework is based on the Java Servlet technology and, to a lesser extent, JavaServer Pages, and therefore is dependent on a web container. For Struts developers, understanding how the web container processes client requests is fundamental to a deeper understanding of the framework itself. This chapter illustrates the various components that are part of the web container and discusses each component's responsibilities.
This section presents a high-level architectural view of a Struts application. Although this section shows an architecture for an enterprise application, not all applications written using Struts will be of this size and makeup. However, this type of application does allow us to present many facets of how Struts applications may be configured.
Many applications—especially J2EE applications—can be described in terms of their tiers. The application's functionality is separated across these tiers, or functional layers, to provide separation of responsibility, reusability, improved scalability, and many other benefits. The separation of tiers may be a physical separation where each is located on a separate hardware resource, or it may be purely logical. In the latter case, one or more tiers are collocated (i.e., arranged or grouped together) on the same hardware resource, and the separation exists in terms of software. Figure 2-1 illustrates the tiers that may be used by a typical Struts application.
Figure 2-1: Functional application tiers
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
An Architecture Overview
Content preview·Buy reprint rights for this chapter
This section presents a high-level architectural view of a Struts application. Although this section shows an architecture for an enterprise application, not all applications written using Struts will be of this size and makeup. However, this type of application does allow us to present many facets of how Struts applications may be configured.
Many applications—especially J2EE applications—can be described in terms of their tiers. The application's functionality is separated across these tiers, or functional layers, to provide separation of responsibility, reusability, improved scalability, and many other benefits. The separation of tiers may be a physical separation where each is located on a separate hardware resource, or it may be purely logical. In the latter case, one or more tiers are collocated (i.e., arranged or grouped together) on the same hardware resource, and the separation exists in terms of software. Figure 2-1 illustrates the tiers that may be used by a typical Struts application.
Figure 2-1: Functional application tiers
Not every Struts application will contain all of the tiers illustrated in Figure 2-1. For many smaller applications, the middle tier may consist primarily of a web container that interacts directly with a database in the enterprise information system (EIS) tier.
There are many different types of containers—EJB containers, web containers, servlet containers, and so on. In general, containers provide a hosting environment for software components to run in. Containers provide general services that the components within the environment can use, so that the component developers don't have to worry about providing these services. A web container allows servlets, JSP components, and other Java classes to be deployed and executed within the container. Services such as the Java Naming and Directory Interface (JNDI), connection pooling, and transaction services can be configured at the container level—similar to the way in which EJB containers manage security, transactions, and bean pooling—and the component developers don't have to worry about managing these resources.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
The HTTP Request/Response Phase
Content preview·Buy reprint rights for this chapter
To better illustrate how the web server and servlet container work together to service clients, this section discusses the protocol for an HTTP request and response, from the time a client request is received until the server returns a response. Struts makes heavy use of the request and response objects, and a complete understanding of the round-trip process will help clarify some topics discussed later in the book.
Although the browser is not the only type of client that can be used with Struts, it certainly is the most common. More and more developers are starting to use Struts for wireless applications and even some interaction with web services, but the web browser remains the predominant client.
HTTP is based on a request/response model, so there are two types of HTTP messages: the request and the response. The browser opens a connection to a server and makes a request. The server processes the client's request and returns a response. Figure 2-3 illustrates this process.
Figure 2-3: The HTTP request/response model
Both types of messages consist of a start line, zero or more header fields, and an empty line that indicates the end of the message headers. Both message types also may contain an optional message body.
The format and makeup of the request and response messages are very similar, but there are a few differences. We'll discuss each type of message separately.
The start line of an HTTP request is known as the request line. It's always the first line of the request message, and it contains three separate fields:
  • An HTTP method
  • A universal resource identifier (URI)
  • An HTTP protocol version
Although there are several HTTP methods for retrieving data from a server, the two used most often are
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Struts and Scope
Content preview·Buy reprint rights for this chapter
The Struts framework uses various shared resource areas to store objects. The shared resource areas all have a lifetime and visibility rule that defines the scope of the resource. This section discusses these resources, their scopes, and how the framework uses them.
Each time a client issues an HTTP request, the server creates an object that implements the javax.servlet.http.HttpServletRequest interface. Among other things, this object contains a collection of key/value attribute pairs that can be used to store objects for the lifetime of the request. The key of each pair is a String, and the value can be any type of Object. The methods to store objects in and retrieve them from the request scope are: 
public void setAttribute( String name, Object obj );
public Object getAttribute( String name );
Request-scope attributes can be removed using the removeAttribute( ) method; however, because the scope of the attribute is only for the lifetime of the request, it is not as important to remove them as it is for other scoped attributes. Once the server fulfills a request and a response is returned to the client, the request and its attributes are no longer available to the client and may be garbage-collected by the JVM.
The Struts framework provides the ability to store JavaBeans in a request, so that they can be used by presentation components such as JSP pages. This makes it much easier to access JavaBeans data, without having to do a manual cleanup of the objects later. There's seldom a need to remove objects from request scope; the web container takes care of it for you. Objects stored at the request level are visible only to resources that have access to that request. Once the response has been returned to the client, the visibility is gone. Objects that are stored in one request are not visible to any other client request.
The next-higher level of visibility is session scope. The web container creates an object that implements the
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Using URL Parameters
Content preview·Buy reprint rights for this chapter
URL parameters are strings that are sent to the server with the client request. The parameters are inserted into the HttpServletRequest object from the URI query string and data that is sent in a POST method. The parameters are formatted as key/value pairs and are accessed by applications as request parameters. URL parameters play an important role in all web applications, and the Struts framework is no exception.
Don't get request parameters confused with request attributes. Attributes are objects that typically are inserted into the request so that they can be made available to other servlets, such as JSP pages.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Forward Versus Redirect
Content preview·Buy reprint rights for this chapter
It's often necessary for more than one component to share control of a request. For example, one servlet may be responsible for authenticating and authorizing a client, while it's the job of a different servlet to retrieve some data for the user. The sharing of a request can be accomplished in several different ways.
There are important differences between how a web container processes a forward request versus how it processes a redirect. The Struts front controller servlet, discussed in Chapter 1, will always perform one or the other for a typical request, so it's important that you understand these differences and the impact that each mechanism will have on your application.
When the sendRedirect( ) method is invoked, it causes the web container to return to the browser a response indicating that a new URL should be requested. Because the browser issues a completely new request, any objects that are stored as request attributes before the redirect occurs will be lost. This is one of the biggest differences between a forward and redirect. Figure 2-5 illustrates why this occurs.
Figure 2-5: A redirect causes the browser to issue a new request
Because of the extra round trip that occurs, a redirect is slower than a forward. Example 2-1 provides an example servlet that performs a redirect for a JSP page called result.jsp when a request for the servlet is issued.
Example 2-1. A Java servlet that performs a redirect when it receives a request 
package com.oreilly.struts.chapter2examples;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.RequestDispatcher;

/**
 * Perform a redirect for the page "redirect.jsp"
 */
public class RedirectServlet extends HttpServlet {

  public void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException{
    redirect( request, response );
  }

  public void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException{
    redirect( request, response );
  }
  /**
   * Set a few URL parameters and objects for the request to see what happens
   * to them during a redirect.
   */
  protected void redirect(HttpServletRequest req,HttpServletResponse resp)
    throws ServletException, IOException{
    log( "A request arrived for " + req.getServletPath(  ) );

    // Put some objects into request scope
    req.setAttribute( "firstName", "John" );
    req.setAttribute( "lastName", "Doe" );

    String contextPath = req.getContextPath(  );
    String redirectStr = contextPath + "/result.jsp?username=foo&password=bar";

    log( "redirecting to " + redirectStr );

    // Always call the encodeRedirectURL(  ) method when perfoming a redirect
    resp.sendRedirect( resp.encodeRedirectURL(redirectStr) );
  }
}
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Chapter 3: Overview of the Struts Framework
Content preview·Buy reprint rights for this chapter
It's finally time to introduce the Struts framework. Familiarity with the material from the previous two chapters will allow you to absorb the information here much faster. This chapter provides an overview of the Struts framework. It does not attempt to cover all of its features or go into significant depth; instead, it emphasizes how all the pieces fit into the MVC and Model 2 architecture presented in Chapter 1.
The rest of the book will be spent pulling back the layers and uncovering the details of the framework, expanding on the basic concepts and terminology introduced here. It is important that you have a firm grasp of the fundamentals presented in this chapter—even if you are familiar with the basic concepts of the Struts framework, you should read through this chapter before going on.
This section introduces an online banking application that will be used to familiarize you with Struts. The example presented here is not complete, but it provides an overview of the major components that are present in all Struts applications and shows how those components fit together. A more comprehensive and thorough shopping-cart example will be used throughout the rest of the book.
Most people are familiar with the concept of online banking, so we won't spend too much time explaining the business requirements. In short, the online banking application will allow an end user to log in to the financial institution's web site, view account information, and transfer funds from one account to another (assuming the user has more than one account). The user must present a valid set of credentials to enter the site—in this case, an access number and a personal identification number (PIN).
If the user leaves one or both fields blank, the application will display a formatted message informing the user that both fields are required. If the user enters values for both fields but the authentication fails, the login screen will be redisplayed, along with a formatted error message informing the user that the login has failed. Figure 3-1 shows the online banking login screen after an invalid login attempt has been detected.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
A Banking Account Example
Content preview·Buy reprint rights for this chapter
This section introduces an online banking application that will be used to familiarize you with Struts. The example presented here is not complete, but it provides an overview of the major components that are present in all Struts applications and shows how those components fit together. A more comprehensive and thorough shopping-cart example will be used throughout the rest of the book.
Most people are familiar with the concept of online banking, so we won't spend too much time explaining the business requirements. In short, the online banking application will allow an end user to log in to the financial institution's web site, view account information, and transfer funds from one account to another (assuming the user has more than one account). The user must present a valid set of credentials to enter the site—in this case, an access number and a personal identification number (PIN).
If the user leaves one or both fields blank, the application will display a formatted message informing the user that both fields are required. If the user enters values for both fields but the authentication fails, the login screen will be redisplayed, along with a formatted error message informing the user that the login has failed. Figure 3-1 shows the online banking login screen after an invalid login attempt has been detected.
Figure 3-1: Login screen for the online banking application
If the proper credentials are entered for an account, the user is taken to the account information screen. This screen shows all of the accounts that the user has with the financial institution, as well as the current balance for each account.
For this example, we are not going to provide a robust, full-fledged security service and security realm. Handling security in a web application can be complicated, and there's no reason to muddy the waters with it at the moment. For the purposes of this chapter, we'll use a simple Java interface that contains a single
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Looking at the Big Picture
Content preview·Buy reprint rights for this chapter
Now that we have described the example application that will be the basis of this chapter's discussion, it's time to start looking at how we can implement it using the Struts framework. Although Chapter 1 discussed the MVC pattern in the order of model, view, and then controller, it doesn't necessarily make sense to follow that order as we explore the Struts components. In fact, it's more logical to cover the components in the order in which the Struts framework uses them to process a request. Thus, we'll discuss the components that make up the controller portion of the framework first.
The Struts framework is made up of approximately 300 Java classes, divided into 8 core packages ("approximately" is an appropriate term because the framework is continuously growing and being shaped). In this chapter, we'll focus on only the top-level packages. Figure 3-4 shows the top-level packages and their dependencies within the framework.
Figure 3-4: The eight top-level packages in the Struts framework
The package shown in Figure 3-4 does not represent the entire set of classes and interfaces necessary for the Validator framework. These are only the Struts-specific extensions necessary to use the Validator framework with Struts.
The framework components are not arranged by what role they play in the MVC pattern—actually, they are arranged a little haphazardly. You might have noticed this by some of the circular dependencies shown in Figure 3-4. This has to do more with how fast the framework has evolved than with poor decisions made by the designers. For example, the action package contains classes for the controller, some that are used by the view domain, and even a few that probably would have been better off in the util package. While it may be confusing at first, it's not that hard to get accustomed to where everything is. Table 3-1 enumerates the top-level packages and provides brief descriptions of their purposes. A few of these top-level packages also contain subpackages, which will be covered in later chapters.
Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!
Struts Controller Components
Content preview·Buy reprint rights for this chapter
The controller component in an MVC application has several responsibilities, including receiving input from a client, invoking a business operation, and coordinating the view to return to the client. Of course, the controller may perform many other functions, but these are a few of the primary ones.
For an application built using the JSP Model 2 approach, the controller is implemented by a Java servlet. This servlet is the centralized point of control for the web application. The controller servlet maps user actions into business operations and then helps to select the view to return to the client based on the request and other state information. As a reminder, Figure 3-5 shows the figure used in Chapter 1 to illustrate how this works.
Figure 3-5: The Struts framework uses a servlet as a contr

Return to Programming Jakarta Struts