As explained in Chapter 2, Struts configuration files are specified inside in the web.xml deployment descriptor file when defining the use of the Struts ActionServlet, as shown here:
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> ... </web-app>
The Struts configuration file is specified by declaring a servlet initialization parameter named config. The config parameter must be set to the Web application-relative path of your configuration file, which will be underneath the protected /WEB-INF/ directory so that it can be accessed only from server-side applications.
As of version 1.1, Struts supports the use of multiple configuration files. This way, configuration settings can be broken down into separate files, which allows teams of developers to work on an application in parallel without having the configuration file be a point of contention. To specify multiple configuration files, simply list each configuration file delimited by commas, as shown here:
<init-param> <param-name>config</param-name> <param-value> /WEB-INF/struts-config.xml, /WEB-INF/struts-config2.xml, /WEB-INF/struts-config3.xml, </param-value> </init-param>
When Struts loads the configuration files, if there is any overlap among the files' settings, Struts will use the last settings specified. For example, if configuration file A specifies a setting and then configuration file B specifies the same setting with a different value, the setting in configuration file B will override the one in configuration file A, provided that file B is loaded after file A.
In addition to support for multiple configuration files, Struts version 1.1 added support for application modules. The module feature allows applications to be broken down into discrete chunks and can be thought of as being almost a mini-application inside of a large application. Using modules requires you to create a separate configuration file for each module, as shown here:
<servlet> <servlet-name>action</servlet-name> <servlet-class>org.apache.struts.action.ActionServlet</servlet-class> <init-param> <param-name>config</param-name> <param-value>/WEB-INF/struts-config.xml</param-value> </init-param> <init-param> <param-name>config/ModuleA</param-name> <param-value>/WEB-INF/struts-config-moduleB.xml</param-value> </init-param> <init-param> <param-name>config/ModuleB</param-name> <param-value>/WEB-INF/struts-config-moduleA.xml</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet>
Notice that the second and third init-param definitions specify parameters named config/ moduleA and config/ModuleB, respectively. Struts uses the part of the name following the slash (/) as the logical name for the module and loads and associates the specified configuration file with that module. Thus, for a parameter named config/ModuleA, the module's name is ModuleA. For module configuration files, parameter names must begin with config/ in order for Struts to recognize them. When using modules, you still need to define a default configuration file for your application with the config parameter, as you would with a nonmodular application.
Note | For more information on using Struts modules, refer to Chapter 9. |