Configuring the web.xml Deployment Descriptor

 < Day Day Up > 

As explained in Chapter 2, Struts configuration files are specified inside in the web.xml deployment descriptor file when defining the use of Struts’ ActionServlet, as shown here:

<!DOCTYPE web-app   PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN"   ""> <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 discreet 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.


For more information on using Struts modules, refer to Chapter 9.

 < Day Day Up > 

Struts. The Complete Reference
Struts: The Complete Reference, 2nd Edition
ISBN: 0072263865
EAN: 2147483647
Year: 2003
Pages: 134
Authors: James Holmes

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: