Struts: The Complete Reference, 2nd Edition

Overview

During the 1.1 release cycle of Struts, a significant number of new features were added to the framework. Each of these features greatly improved the framework, and each is important in its own right. However, one feature stands out because of its profound impact on the framework: support for modules.

Support for modules solves a problem commonly encountered when using earlier versions of Struts. In all versions of Struts, including version 1.1, you can run only one instance of the ActionServlet controller servlet per Web application (i.e., .war file). This is because ActionServlet stores several details of the framework's configuration in variables within the Web application scope, which is the scope shared by all parts of the application. Thus, attempting to run multiple instances of ActionServlet in the same Web application causes a problem, because the data associated with one instance overwrites the data associated with another instance. Prior to version 1.1 and its introduction of modules, this was a major limitation of Struts, because your entire application's configuration had to reside in a single Struts configuration file. For large applications, where the configuration file gets very large and several developers are involved, that proved to be a problematic point of contention.

Today, you still can have only one instance of ActionServlet for the same reasons as before; however, you can simulate the functionality of having multiple instances by subdividing your application into discreet units by using modules. Each module has its own Struts configuration file, its own set of actions and forwards, a separate URL namespace, and so on. Essentially, modules are like mini-Struts applications inside a master Struts application and are analogous to the way Web applications reside in a servlet container. Each module has its own URL namespace, just as Web applications do. Modules also solve the problems of parallel development that are commonly experienced when using versions of Struts prior to 1.1.

Before moving on, it is necessary to mention another feature added by Struts 1.1 that, in some cases, offers an alternative to modules: support for multiple configuration files. Although added in the same release (1.1) as modules, multiple configuration files can be used independently, without having to convert your application for use with modules. Support for multiple configuration files alleviates some of the problems associated with large, team-based development with Struts. However, multiple configuration files do not partition your Struts application the way that modules do. When using multiple configuration files, the information in the files is combined to create one large set of configuration data. This can cause a problem, however. For example, if you define an action with a certain name in one file and another configuration file defines another action with the same name, the configuration file last read will override the first file's data. Basically, last one in wins. Modules do not have this problem, because Struts stores each module's configuration data separately. Thus, modules offer the best solution when you need the functionality of multiple instances of ActionServlet.

This chapter describes how to set up and use modules in your application, including details on how to use Tiles and Validator with modules. It also shows how to apply modules to the Mini HR application.