0. Preface: Core Technologies

This User Guide is written for active web developers and assumes a working knowledge about how Java web applications are built. Before getting started, you should understand the basics of several core technologies:

• HTTP, HTML, and User Agents
• The HTTP Request/Response Cycle
• The Java Language and Application Frameworks
• JavaBeans
• Properties Files and ResourceBundles
• Java Servlets
• JavaServer Pages and JSP Tag Libraries
• Extensible Markup Language

This chapter briefly defines each of these technologies but does not describe them in detail. For your convenience, links to further information are provided if you would like to learn more about a technology.

If you are familiar with Java, but not these technologies, the best overall starting point is The Java Web Services Tutorial . This document is also available for download in PDF format.

If you've created web applications for other platforms, you may be able to follow along and visit the other references as needed. The core technologies used by Struts are also used by most other Java web development products, so the background information will be useful in any Java project.

If you are not familiar with the Java language generally, then the best starting point is The Java Tutorial . This overlaps with the Java Web Services Tutorial in some places, but the two work well together.

For more about building Java application in general, see the New to Java tutorial.

The World Wide Web was built over the Hypertext Transfer Protocol (HTTP) and the Hypertext Markup Language (HTML). A User Agent, like a web browser, uses HTTP to request a HTML document. The browser then formats and displays the document to its user. HTTP is used to transport more than HTML, but HTML is the lingua franca of the Web and web applications.

While building web applications, some Java developers will write their own HTML. Others leave that responsibility to the page designers.

For more about HTTP, HTML, and User Agents, see:

• Getting started with HTML by Dave Raggett
• HTTP Overview in the Java Web Services Tutorial.
• HTTP/1.1 Specification
• HTTP Basic and Digest Authentication Specification
• State Management Mechanism Specification (Cookies)

A very important part of HTTP for the web developer is the request/response cycle. To use HTTP you have to make a request. A HTTP server, like a web server, is then obliged to respond. When you build your web application, you design it to react to a HTTP request by returning a HTTP response. Frameworks like Struts abstract much of these nuts and bolts, but it is important to understand what is happening behind the scenes.

If you are not familiar with the HTTP request/response cycle, we strongly recommend the HTTP Overview in the Java Web Services Tutorial.

Struts is written in the popular and versatile Java programming language. Java is an object-orientated language, and Struts makes good use of many object-orientated techniques. In addition, Java natively supports the concept of threads, which allows more than one task to be performed at the same time. A good understanding of Java, and especially object-orientated programming (OOP) and threading, will help you get the most out of Struts and this User Guide.

For more about Java and threads, see

• Learning the Java Language in the Java Tutorial
• Threads: Doing Two or More Tasks At Once in the Java Language Tutorial

Even if you have worked with Java and OOP before, it can also help to be aware of the programming challenges specific to creating and using application frameworks. For more about application frameworks, see the classic white papers

• Designing Reusable Classes by Ralph E. Johnson & Brian Foote
• Object-Oriented Application Frameworks by Mohamed Fayad and Douglas C. Schmidt

These papers can be especially helpful if you are fact-finding or reviewing server-side frameworks.

Like many Java applications, most of the Struts objects are designed as JavaBeans. Following the JavaBean design patterns makes the Struts classes easier to use -- both by Java developers and by Java development tools.

Although JavaBeans were first created for visual elements, these object design patterns have been found to be useful as the basis for any reusable component, like those used by the Struts framework.

For more about JavaBeans, see:

• The JavaBeans Component Architecture Documentation page at java.sun.com, including a link to download the JavaBeans 1.01 Specification
• The JavaBean Trail in the Java Tutorial
• JavaBeans Components in JSP Pages in the Java Web Services Tutorial

Reflection is the process of determining which member fields and methods are available on an object. Introspection is a specialized form of reflection used by the JavaBean API. Using Introspection, we can determine which methods of a JavaBean are intended to be accessed by other objects. (The getters and the setters, for example.)

The Struts framework uses Introspection to convert HTTP parameters into JavaBean properties and to populate HTML fields from JavaBean properties. This technique makes it easy to "roundtrip" properties between HTML forms and JavaBeans.

For more about Reflection and Introspection, see

• The Reflection Trail
• Chapter 8 of the JavaBeans API Specification

JavaBeans store data as properties and may act on that data through other methods. JavaBeans are flexible and powerful objects but are not the only object that programmers use to store data. Another popular object is the Map [java.util.Map]. A Map is a simple collection of name and value pairs. Maps are often used "behind the scenes" as a flexible way to store dynamic data.

DynaBeans combine the extensibility of JavaBeans with the flexibility of a Map. Defining even the simplest JavaBean requires defining a new class and coding a field and two methods for each property. The properties of a DynaBean can be configured via an XML descriptor. The virtual properties of a DynaBean can't be called by standard Java methods, but work well with components that rely on reflection and introspection.

In a Struts application, you can use DynaBeans to describe your HTML forms. This strategy can avoid creating a formal JavaBean subclass to store a few simple properties.

For more about DynaBeans, see

• The Commons BeanUtils Package Description and Javadocs.

Java applications, including web applications, are often configured using Properties files. Properties files are the basis for the ResourceBundles that Struts uses to provide message resources to an application.

For more about Properties files, see:

• Using Properties to Manage Program Attributes in The Java Tutorial

Java ResourceBundles use one or more Properties files to provide internationalized messages to users based their Locale. Support for localizing an application was built into Struts from the ground-up.

For more about localization and ResourceBundles, see

• About the ResourceBundle Class in the Java Tutorial

Since Java is an object-orientated language, the Java Servlet platform strives to cast HTTP into an object-orientated form. This strategy makes it easier for Java developers to concentrate on what they need their application to do -- rather than the mechanics of HTTP.

HTTP provides a standard mechanism for extending servers called the Common Gateway Interface, or CGI. The server can pass a request to a CGI-aware program, and the program will pass back a response. Likewise, a Java-aware server can pass a request to a servlet container. The container can fulfill the request or it can pass the request back to the HTTP server. The container decides whether it can handle the request by checking its list of servlets. If there is a servlet registered for the request, the container passes the request to the servlet.

When a request comes in, the container checks to see if there is a servlet registered for that request. If there is a match, the request is given to the servlet. If not, the request is returned to the HTTP server.

It's the container's job to manages the servlet lifecycle. The container creates the servlets, invokes the servlets, and ultimately disposes the servlets.

A servlet is generally a subclass of javax.servlet.http.HttpServlet. A servlet must implement four methods, which are invoked by the container as needed:

• public void init(ServletConfig config) - Called by the servlet container when the servlet instance is first created, and before any request is processed.
• public void doGet(HttpServletRequest request, HttpServletResponse response) - Called to process a specific request received using the HTTP GET protocol, which generates a corresponding dynamic response.
• public void doPost(HttpServletRequest request, HttpServletResponse response) - Called to process a specific request received using the HTTP POST protocol, which generates a corresponding dynamic response.
• public void destroy() - Called by the servlet container when it takes this servlet instance out of service, such as when a web application is being undeployed or when the entire container is being shut down.

Struts provides a ready-to-use servlet for your application [org.apache.struts.action.ActionServlet]. As a Struts developer, you can then just write objects that the Struts ActionServlet calls when needed. But it is still helpful to understand the basics of what servlets are, and the role they play in a Java web application.

For more about Java Servlets, see:

• The Java Servlet Technology page at java.sun.com
• The Servlet 2.2 and 2.3 Specifications download page at java.sun.com
• Java Servlet Technology in the Java Web Services Tutorial.
• Web Applications in the Java Web Services Tutorial.

To boost performance, the container can multi-thread servlets. Only one instance of a particular servlet is created, and each request for that servlet passes through the same object. This strategy helps the container make the best use of available resources. The tradeoff is that the servlet's doGet() and doPost() methods must be programmed in a thread-safe manner.

For more about servlets and thread-safety, see:

• Controlling Concurrent Access to Shared Resources in Java Web Services Tutorial.

The ServletContext interface [javax.servlet.ServletContext] defines a servlet's view of the web application within which the servlet is running. It is accessible in a servlet via the getServletConfig() method, and in a JSP page as the application implicit variable. Servlet contexts provide several APIs that are very useful in building Struts based web applications:

• Access To Web Application Resources - A servlet can access static resource files within the web application using the getResource() and getResourceAsStream() methods.
• Servlet Context Attributes - The context makes available a storage place for Java objects, identified by string-valued keys. These attributes are global to the entire web application, and may be accessed by a servlet using the getAttribute(), getAttributeNames(), removeAttribute(), and setAttribute() methods. From a JSP page, servlet context attributes are also known as "application scope beans".

For more about the servlet context, see:

• Accessing the Web Context in Java Web Services Tutorial.

Each request processed by a servlet is represented by a Java interface, normally a HttpServletRequest [javax.servlet.http.HttpServletRequest]. The request interface provides an object-oriented mechanism to access all of the information that was included in the underlying HTTP request, including:

• Cookies - The set of cookies included with this request are available via the getCookies() method.
• Headers - HTTP headers that were included with the request are accessible by name. You can enumerate the names of all included headers.
• Parameters - Request parameters, including those from the query string portion of the URL and from the embedded content of the request (POST only) are available by name.
• Request Characteristics - Many other characteristics of the incoming HTTP request, such as the method used (normally GET or POST) the protocol scheme used ("http" or "https"), and similar values.
• Request URI Information - The original request URI being processed is available via getRequestURI(). In addition, the constituent parts into which the servlet container parses the request URI (contextPath, servletPath, and pathInfo) are available separately.
• User Information - If you are using Container Managed Security, you can ask for the username of the authenticated user, retrieve a Principal object representing the current user, and whether the current user is authorized for a specified role.

In addition, servlet requests support request attributes (from JSP, these are "request scope beans"), analogous to the servlet context attributes described above. Request attributes are often used to communicate state information from a business logic class that generates it to a view component (such as a JSP page) that will use the information to produce the corresponding response.

The servlet container guarantees that a particular request will be processed by a servlet on a single thread. Therefore, you do not generally have to worry about the thread safety of your access to request properties and attributes.

For more about the servlet request, see:

• Getting Information from Requests in Java Web Services Tutorial.

The primary purpose of a servlet is to process an incoming Servlet Request [javax.servlet.http.HttpServletRequest] and convert it into a corresponding response. This is performed by calling appropriate methods on the servlet response [javax.servlet.http.HttpServletResponse] interface. Available methods let you:

• Set Headers - You can set HTTP headers that will be included in the response. The most important header is the Content-Type header, which tells your client what kind of information is included in the body of this response. This is typically set to text/html for an HTML page, or text/xml for an XML document.
• Set Cookies - You can add cookies to the current response.
• Send Error Responses - You can send an HTTP error status (instead of a usual page of content) using sendError().
• Redirect To Another Resource - You can use the sendRedirect() method to redirect the client to some other URL that you specify.

An important principle in using the servlet response APIs is that any methods you call to manipulate headers or cookies MUST be performed before the first buffer-full of content has been flushed to the client. The reason for this restriction is that such information is transmitted at the beginning of the HTTP response, so trying things like adding a header after the headers have already been sent will not be effective.

When you are using presentation pages in a Model 2 application, you will not generally use the servlet response APIs directly. In the case of JavaServerPages, the JSP page compiler in your servlet container will convert your page into a servlet. The JSP servlet renders the response, interspersing dynamic information where you have interposed JSP custom tags.

Other presentation systems, like Velocity Tools for Struts, may delegate rendering the response to a specialized servlet, but the same pattern holds true. You create a template, and the dynamic response is generated automatically from the template.

For more about the servlet response, see:

• Constructing Responses in Java Web Services Tutorial.

If you are using a servlet container based on version 2.3 or later of the Servlet Specification (such as Tomcat 4.x), you can take advantage of the new Filter APIs [javax.servlet.Filter] that let you compose a set of components that will process a request or response. Filters are aggregated into a chain in which each filter has a chance to process the request and response before and after it is processed by subsequent filters (and the servlet that is ultimately called).

The Struts 1.x series (versions 1.0, 1.1, and so forth) require only version 2.2 or later of the Servlet Specification to be implemented by your servlet container, so Struts does not itself utilize Filters at this time. The next generation of Struts (the 2.x series) will be based on Servlet 2.3 or later. It is likely that the Struts 2.x release series will utilize filters.

For more about filters, see:

• Filtering Requests and Responses

One of the key characteristics of HTTP is that it is stateless. In other words, there is nothing built in to HTTP that identifies a subsequent request from the same user as being related to a previous request from that user. This makes building an application that wants to engage in a conversation with the user over several requests to be somewhat difficult.

To alleviate this difficulty, the servlet API provides a programmatic concept called a session, represented as an object that implements the javax.servlet.http.HttpSession interface. The servlet container will use one of two techniques (cookies or URL rewriting) to ensure that the next request from the same user will include the session id for this session, so that state information saved in the session can be associated with multiple requests. This state information is stored in session attributes (in JSP, they are known as "session scope beans").

To avoid occupying resources forever when a user fails to complete an interaction, sessions have a configurable timeout interval. If the time gap between two requests exceeds this interval, the session will be timed out, and all session attributes removed. You define a default session timeout in your web application deployment descriptor, and you can dynamically change it for a particular session by calling the setMaxInactiveInterval() method.

Unlike requests, you need to be concerned about thread safety on your session attributes (the methods these beans provide, not the getAttribute() and setAttribute() methods of the session itself). It is surprisingly easy for there to be multiple simultaneous requests from the same user, which will therefore access the same session.

Another important consideration is that session attributes occupy memory in your server in between requests. This can have an impact on the number of simultaneous users that your application can support. If your application requirements include very large numbers of simultaneous users, you will likely want to minimize your use of session attributes, in an effort to control the overall amount of memory required to support your application.

For more about sessions, see:

• Maintaining Client State in Java Web Services Tutorial
• javax.servlet.http.HttpSession

The Java Servlet specification extends the HTTP request/response cycle by allowing the request to be dispatched, or forwarded, between resources. Struts uses this feature to pass a request through specialized components, each handling one aspect of the response. In the normal course, a request may pass through a controller object, a model object, and finally to a view object as part of a single request/response cycle.

Just as a HTTP server can be used to host several distinct web sites, a servlet container can be used to host more than one web application. The Java servlet platform provides a well-defined mechanism for organizing and deploying web applications. Each application runs in its own namespace so that they can be developed and deployed separately. A web application can be assembled into a Web Application Archive, or WAR file. The single WAR can be uploaded to the server and automatically deployed.

For more about web applications, see:

• Web Applications in Java Web Services Tutorial

Most aspects of an application's lifecycle are configured through an XML document called the Web application deployment descriptor. The schema of the descriptor, or web.xml, is given by the Java servlet specification.

For more about the web.xml and application lifecycle events, see:

• Web Application Life Cycle in Java Web Services Tutorial

One detail that can be configured in the Web application deployment descriptor is container-managed security. Declarative security can be used to protect requests for URIs that match given patterns. Pragmatic security can be used to fine-tune security make authorization decisions based on the time of day, the parameters of a call, or the internal state of a Web component. It can also be used to restrict authentication based on information in a database.

For more information about container-managed security, see:

• Web Application Security (Chapter 24) in the Java Web Services Tutorial

JavaServer Pages (JSPs) are "inside-out servlets" that make it easier to create and maintain dynamic web pages. Instead of putting what you want to write to the HTTP response inside of a Java print statement, everything in a JavaServer Page is written to the response, except what is placed within special Java statements.

With JavaServer Pages you can start by writing the page in standard HTML and then add the dynamic features using statements in the Java language or by using JSP tags. The Struts distribution includes several JSP tags that make it easy to access the framework's features from a JavaServer Page.

For more about JavaServerPages and Custom JSP Tag Libraries see

• The JavaServer Pages Technology page at java.sun.com
• The JSP 1.1 and 1.2 Specifications download page at java.sun.com
• JavaServer Pages Technology in the Java Web Services Tutorial
• Custom Tags in JSP Pages in the Java Web Services Tutorial

Many times, JSP tags work hand-in-hand with JavaBeans. The application sends a JavaBean to the JSP, and the JSP tag uses the bean to customize the page for the instant user. For more, see JavaBeans Components in JSP Pages in the Java Web Services Tutorial.

Struts also works well with the new JavaServer Pages Standard Tag Library (JSTL) and taglibs from other sources, like JSP Tags and Jakarta Taglibs.

One of the contributed libraries available for Struts is Struts-EL. This taglib is specifically designed to work well with JSTL. In particular, it uses the same "expression language" engine for evaluating tag attribute values as JSTL. This is in contrast to the original Struts tag library, which can only use "rtexprvalue"s (runtime scriptlet expressions) for dynamic attribute values.

There are also toolkits available that make Struts easy to use with XSLT and Velocity Templates.

The newest star on the Java horizon is Java Server Faces. JavaServer Faces technology simplifies building user interfaces for JavaServer applications, both for the web and for the desktop. The JSF specification is still under development, although an early-release reference implementation is available through the Java Web Services Developer Pack. Likewise, an early-release JavaServer Faces taglib for Struts, Struts-Faces , is also in early release and available through the nightly build.

Java Server Faces is very compatible with Struts. Additional Struts/JSF integration tools are sure to appear as the specification is finalized and comes into widespread use.

For more about JSTL and JavaServer Faces see

• Practical JSTL, Part 1 by Sue Spielman
• JSF Central - JavaServer Faces resources.
• JavaServer Faces Resources - James Holmes dot Com.

The features provided by the Struts framework relies on a number of objects that are usually deployed using a configuration file written in Extensible Markup Language. XML is also used to configure Java web applications; so, this is yet another familiar approach.

For more about XML configuration files and Java web applications, see

• Configuring Web Applications in the Java Web Services Tutorial

For more about how XML is used with Java applications generally, see Java API for XML Processing in the Java Web Services Tutorial. While the framework makes good use of this API internally, it is not something most Struts developers would use when writing their own applications.

When Java applications use XML configuration files, the elements are most often used as descriptors. The application does not use the XML elements directly. The elements are used to create and configure (or deploy) Java objects.

The Java Servlet platform uses an XML configuration file to deploy servlets (among other things). Likewise, Struts uses an XML configuration file to deploy objects used by the framework.

Struts provides the control layer for a web application. Developers can use this layer with other standard technologies to provide the data access and presentation layers. Some popular Data access technologies include:

• Enterprise Java Beans
• Hibernate
• iBATIS
• JDBC
• Object Relational Bridge

Presentation layer technologies include:

• JavaServer Pages
• Velocity Templates
• XSL Transformations

While Struts can work with any approach to user authentication and authorization, Struts 1.1 and later offers direct support for the standard Java Authentication and Authorization Service (JAAS). You can now specify security roles on an action-by-action basis.

For more about JAAS, see the Javasoft product page and the Web Application Security chapter of the Java Web Services Tutorial.

Next: Introduction