Programming Tutorials

Tutorial on Struts Configuration File - struts-config.xml in Struts - from the book: Struts Survival Guide. Basics to Best Practices

By: Authors: Shenoy S. Mallya N. in Struts Tutorials on 2007-10-01  

The configurable controller is the answer to the Fat controller problem. In a Fat Controller, the programmers can code "if" blocks on need basis. Not so with the configurable controllers. The expressive and configuration capability is limited to what the built-in controller can support. In Struts, the built-in controller supports a variety of cases that can arise while developing web applications. It even provides points to extend the configuration capabilities. These points known as Extension points, take the configuration capability to the next dimension. In this tutorial, we will just look at the normal facilities offered by the strutsconfig.xml.

The Struts configuration file adheres to the struts-config_1_1.dtd. The struts config dtd can be found in the Struts distribution in the lib directory. It shows every possible element, their attributes and their description. Covering all of them at once would only result in information overload. Hence we will only look at the five important sections of this file relevant to our discussion and their important attributes. In fact we have already covered most of these in the lifecycle discussion earlier, but are summarizing them again to refresh your mind.

The five important sections are:

1. Form bean definition section
2. Global forward definition section
3. Action mapping definition section
4. Controller configuration section
5. Application Resources definition section

Listing below shows a sample Struts Config file showing all the five sections. The form bean definition section contains one or more entries for each ActionForm. Each form bean is identified by a unique logical name. The type is the fully qualified class name of the ActionForm. An interesting to note is that you can declare the same ActionForm class any number of times provided each entry has a unique name associated with it. This feature is useful if you want to store multiple forms of the same type in the servlet session.

Table: Important attributes and elements of ActionMapping entry in struts-config.xml

The ActionMapping section contains the mapping from URL path to an Action class (and also associates a Form bean with the path). The type attribute is the fully qualified class name of the associated Action. Each action entry in the action-mappings should have a unique path. This follows from the fact that each URL path needs a unique handler. There is no facility to associate multiple Actions with the same path. The name attribute is the name of the Form bean associated with this Action. The actual form bean is defined in Form bean definition section. Table above shows all the relevant attributes discussed so far for the action entry in action-mappings section.

//Sample struts-config.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE struts-config PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 1.1//EN" "http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">
<struts-config> Form bean Definitions <form-beans>
        <form-bean name="CustomerForm"
            type="mybank.example.CustomerForm" />
        <form-bean name="LogonForm"
            type="mybank.example.LogonForm" />
    </form-beans> Global Forward Definitions <global-forwards>
        <forward name="logon" path="/logon.jsp" />
        <forward name="logoff" path="/logoff.do" />
    </global-forwards> Action Mappings <action-mappings>
        <action path="/submitDetailForm"
            type="mybank.example.CustomerAction"
            name="CustomerForm"
            scope="request"
            validate="true"
            input="/CustomerDetailForm.jsp">
            <forward name="success"
                path="/ThankYou.jsp"
                redirect="true" />
            <forward name="failure"
                path="/Failure.jsp" />
        </action>
        <action path="/logoff" parameter="/logoff.jsp"
            type="org.apache.struts.action.ForwardAction" />
    </action-mappings> Controller
    Configuration <controller
        processorClass="org.apache.struts.action.RequestProcessor" />
<message-resources
        parameter="mybank.ApplicationResources" />
</struts-config> 

Message Resource Definition

In the ActionMapping there are two forwards. Those forwards are local forwards – which means those forwards can be accessed only within the ActionMapping. On the other hand, the forwards defined in the Global Forward section are accessible from any ActionMapping. As you have seen earlier, a forward has a name and a path. The name attribute is the logical name assigned. The path attribute is the resource to which the control is to be forwarded. This resource can be an actual page name as in

<forward name="logon" path="/logon.jsp"/>

or it can be another ActionMapping as in

<forward name="logoff" path="/logoff.do "/>

The /logoff (notice the absence of ".do") would be another ActionMapping in the struts-config.xml. The forward - either global or local are used in the execute() method of the Action class to forward the control to another physical page or ActionMapping.

The next section in the config file is the controller. The controller is optional. Unless otherwise specified, the default controller is always the org.apache.struts.action.RequestProcessor. There are cases when you want to replace or extend this to have your own specialized processor. For instance, when using Tiles (a JSP page template framework) in conjunction with Struts, you would use TilesRequestProcessor.

The last section of immediate interest is the Message Resource definition. In the ActionErrors discussion, you saw a code snippet that used a cryptic key as the argument for the ActionError. We stated that this key maps to a value in a properties file. Well, we declare that properties file in the struts-config.xml in the Message Resources definition section. The declaration in Listing above states that the Message Resources Bundle for the application is called ApplicationResources.properties and the file is located in the java package mybank.

If you are wondering how (and why) can a properties file be located in a java package, recall that any file (including class file) is a resource and is loaded by the class loader by specifying the package.