"The time has come," the Walrus said, "To talk of many things: Of shoes -- and ships -- and sealing-wax -- Of cabbages -- and kings -- And why the sea is boiling hot -- And whether pigs have wings."
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 key technologies:
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 the framework 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 J2EE Tutorial in some places, but the two work well together.
For more about building Java application in general, see the New to Java Center.
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 write their own HTML. Others leave that responsibility to the page designers.
For more about HTTP, HTML, and User Agents, see:
If you are not familiar with the HTTP request/response cycle, we strongly recommend the HTTP Overview in The J2EE Tutorial.
The framework is written in the popular and versatile Java programming language. Java is an object-orientated language, and the framework 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 the framework and this User Guide.
For more about Java and threads, see
A popular technique for organizing the execution of complex processing flows is the "Chain of Responsibility" pattern, as described (among many other places) in the classic "Gang of Four" design patterns book. The GoF summarizes the Chain of Responsibility pattern as "Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it."
The CoR pattern helps us keep software components loosely coupled. A component can call a Chain of Responsbility, without knowing what objects are on the chain or how they are implemented. Most importantly, we can adjust the Chain without changing how callers invoke the Chain. As of version 1.3, the default Request Processor, which acts as the framework's "kernal", is a Chain of Responsiblity.
To implement its Chain, the Request Processor uses the Chain of Responsibility component in the Jakarta Commons which provides a standard implementation of the CoR pattern, along with various implementations of the Context and Command objects used by the Chain to service a request.
For more about Chain of Responsiblity, see
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 framework.
For more about JavaBeans, see:
java.sun.com,including a link to download the JavaBeans 1.01 Specification
The 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
[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 your 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
For more about Properties files, see:
For more about localization and ResourceBundles, see
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
A servlet must implement four methods, which are invoked
by the container as needed:
GETprotocol, which generates a corresponding dynamic response.
POSTprotocol, which generates a corresponding dynamic response.
[org.apache.struts.action.ActionServlet].As a developer, you can then just write objects that the ActionServlet calls when needed. But it is still helpful to understand the servlet essentials, and the role they play in a Java web application.
For more about Java Servlets, see:
doPost()methods must be programmed in a thread-safe manner.
For more about servlets and thread-safety, see:
[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
applicationimplicit variable. Servlet contexts provide several APIs that are very useful in building web applications:
setAttribute()methods. From a JSP page, servlet context attributes are also known as "application scope beans".
[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:
getRequestURI(). In addition, the constituent parts into which the servlet container parses the request URI (contextPath, servletPath, and pathInfo) are available separately.
Principalobject representing the current user, and whether the current user is authorized for a specified role.
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:
[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:
Content-Typeheader, which tells your client what kind of information is included in the body of this response. This is typically set to
text/htmlfor an HTML page, or
text/xmlfor an XML document.
sendRedirect()method to redirect the client to some other URL that you specify.
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:
[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.0, 1.1, and 1.2 versions require only version 2.2 or later of the Servlet Specification to be implemented by your servlet container, so those versions do not use Filters. Beginning with the 1.3 version, a container that supports version 2.3 or later of the Servlet Specification is required, and it is possible that the framework might use Filters in the future.
For more about filters, see:
To alleviate this difficulty, the servlet API provides a
concept called a
represented as an object that
The servlet container will use one of two techniques
URL rewriting) to ensure that the next request from the
same user will
for this session, so that state
information saved in the session can be associated with
requests. This state information is stored in
(in JSP, they are known as "session scope beans").
To avoid occupying resources indefinately when a user fails to
an interaction, sessions have a configurable
If the time gap between two requests exceeds this
interval, the session
will be timed out, and all session attributes removed. You
default session timeout in your web application deployment
and you can dynamically change it for a particular session
Unlike requests, you need to be concerned about thread
your session attributes (the methods these beans provide,
of the session itself). It is surprisingly easy for there
multiple simultaneous requests from the same user, which
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:
Just as a HTTP server can be used to host several distinct websites, 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.
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.
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 about security, see:
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 framework distribution includes several JSP tags that make it easy to access the framework's features from a JavaServer Page.
For more about JavaServer Pages and Custom JSP Tag Libraries see
One of the components available with the framework 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.
The newest star on the Java horizon is JavaServer Faces technology. JSF simplifies building user interfaces for JavaServer applications, both for the web and for the desktop. For teams looking for a step-wise transition to JSF and Struts 1, we offer Struts-Faces taglib, which lets you use JSF components with your existing Actions, so that you can migate to JSF one page a time.
For an open source implementation of JSF, visit our sibling project, Apache MyFaces.
For more about JSTL and JavaServer Faces see
For more about how XML is used with Java applications generally, see the Java API for XML Processing Tutorial. While the framework makes good use of this API internally, it is not something most developers would use when writing their own applications with the framework.
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, The framework uses an XML configuration file to deploy objects.
While the framework can work with any approach to user authentication and authorization, version 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 Sun Developer Network product page.
A popular extension for handling security in a Java web application, including a framework application, is SecurityFilter .
The framework provides the control layer for a web application. Developers can use this layer with other standard technologies to provide the business, data access, and presentation layers.
For more about creating business and data access layers, see the Building Model Components section.
For more about creating the presentation layer, see the Building View Components section.