ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Jakarta Struts: Seven Lessons from the Trenches
Pages: 1, 2, 3, 4

3. Use Application Modules

A new feature of Struts 1.1 is the concept of application modules. Application modules allow a single Struts application to be split into multiple modules, each with its own Struts configuration file, JSP pages, Actions, and so on. This new feature solves one of the biggest complaints that development groups of more than a few people have had for some time: that is, to better support parallel development by allowing for multiple configuration files instead of just one.



Note: earlier in the beta cycle, this feature was being referred to as a "sub-applications," but was changed recently to reflect their more logical responsibility.

A single Struts configuration file easily becomes a resource contention when there are more than a few developers working on a single project. Application modules also allow a Struts application to be broken up based on functional requirements, which proves to be closer to the physical implementation, in many cases. For example, suppose you have a typical storefront application. You might separate the components into modules like catalog, customer, customer service, order, and so on. Each one of these modules may be separated into a distinct directory. This enables the resources for that component to be more easily found, and also helps aid development and deployment. Figure 1 shows a directory structure for an example storefront application.

Figure 1. A directory structure for a typical storefront application.


Note: the Struts framework supports a "default" application module if you don't need to break up your project into multiple modules. This allows applications built with version 1.0 to be portable, because the application automatically becomes the default application module.

To enable multiple application modules, there are several steps that you must perform:

  • Create separate Struts configuration files for each application module.
  • Configure the Web deployment descriptor (Web.xml) file.
  • Use the org.apache.struts.actions.SwitchAction to move between Modules.

Creating Separate Struts Configuration Files

Each Struts application module must have its own configuration file. This allows you to configure separate Actions, ActionForms, exception handling, and much more, independent of other application modules.

Continuing with the storefront example, we might create three configuration files: one called struts-config-catalog.xml, which contains the configuration information for catalogs, items, and other inventory-related functionality; another file called struts- config-order.xml, which contains settings for orders and order tracking; and finally, a third configuration file called struts-config.xml, which contains common functionality that belongs to the default application module.

Configuring the Web Deployment Descriptor

With earlier versions of Struts, you specified the path to the Struts configuration file in the Web.xml file. Fortunately, that's still the same (as it helps to support backwards compatibility), but for multiple application modules, new configuration settings have to be added to the Web deployment descriptor.

For the default application (and earlier versions of Struts), the Struts framework loads the Action mappings and other application settings by looking for an <init-param> element in the web-xml file with a name of config. The following XML fragment shows an example of a typical <init-param> element:

<init-param>
   <param-name>config>/param-name>
   <param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>

Note: the Struts framework will default to /WEB/struts-config.xml if there's no "config" <init-param> element present.

To support multiple application modules, you need to add additional <init-param> elements. The difference between the default <init-param> element and the additional ones for application modules is that the non-default elements must be named config/xxx, where x is a string that represents a unique name for an application module. For example, the <init-param> elements for the storefront application might look like this:

<init-param>
   <param-name>config</param-name>
   <param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
   <param-name>config/catalog</param-name>
   <param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>
<init-param>
   <param-name>config/order</param-name>
   <param-value>/WEB-INF/struts-config.xml</param-value>
</init-param>

The first <init-param> element is for the default application model. The second and third elements represent additional non-default application modules and are named catalog and order, respectively.

When the framework loads an application, it loads the configuration file for the default application module. It then searches for any addition initialization parameters that contain the string config/xxx. Each additional configuration file is parsed and loaded into memory. Once this step is complete, you are free to refer to the multiple application modules by name, where the name of the application module is the string after config/ in the <init-param> element.

Moving Between Application Modules

Once you have created the configuration file for each application module, you then have the ability to invoke Actions in the various modules. To do this, you need to utilize the SwitchAction provided with the framework. The framework will automatically add the application module name to the URL, just as it adds the application name to the URL. The application module feature is a great new addition to the framework and will help with parallel development. There's no requirement to use this feature if your team is small and you don't have a need to modularize your components. The framework works just the same if you only have a single default application module.

Pages: 1, 2, 3, 4

Next Pagearrow