Cavaness C. Programming Jakarta Struts / 4.7 The Digester Component

Computers & Technology
Education & Reference
Business & Investing
Science & Math

Programming Jakarta Struts
Authors: Cavaness C.
Published year: 2003
Pages: 40-42/180

<< Previous page
Table of contents
Next page >>

4.7 The Digester Component

When a Struts application is initialized , one of the first things that it must do is to read and parse the configuration file, which, as you've seen in this chapter, is in XML. The Digester component is a separate Jakarta project made up of several classes that read XML files and create and initialize Java objects based on those files.

The Digester component uses a set of rules, written as a Java class, to invoke callback methods. These methods instantiate and populate the objects with data read from the Struts configuration file.

The Struts framework uses the Digester to parse the configuration files and to create the necessary configuration objects within the org.apache.struts.config package. The rules that the Digester uses for Struts are contained within the org.apache.struts.config.ConfigRuleSet class. There is little need to modify the ConfigRuleSet class unless you need to extend the configuration file. If this is necessary for your application, you should view the documentation for the Digester component before you get started. This can be found at http://jakarta.apache.org/ commons/digester.html .

4.8 The Struts Console Tool

When you're developing a small application, the Struts configuration is manageable. It's still XML, but typically it's not much of a problem. Some developers use XML editors, while others use ordinary text editors. Both of these are fine when the application is relatively small, but when you are working on a large Struts project, the size and complexity of the file can be staggering.

The Struts Console application was created by James Holmes to solve this and other problems associated with managing large configuration files. It is a Swing-based application that provides an easy-to-use interface for editing the various elements of the Struts configuration file.

You can download the Struts Console for free from http://www.jamesholmes.com/ struts/console , even though it's not open source software. No license currently is necessary, but you should check the web site to make sure this hasn't changed.

The formatting of your Struts configuration file might be modified when you save the file using the Console. The Console uses an XML parser to read in the configuration file, and the parser can't maintain complete knowledge of how the file was originally formatted. The Console does provide several output options that you can use to format the XML file based on different formats.

Figure 4-5 shows the action screen from the Struts Console.

Figure 4-5. The action configuration screen from the Struts Console

The Struts Console application also plugs into multiple popular Java integrated development environments (IDEs). Currently, the supported IDEs include:

JBuilder (4.0 or higher)
Eclipse (1.0 or higher)
NetBeans (3.2 or higher)
Oracle JDeveloper (9i or higher)
Sun One Studio (3.0 or higher)

Figure 4-6 shows what the Console application looks like in JBuilder.

Figure 4-6. The Struts Console running in the JBuilder IDE

4.9 Reloading the Configuration Files

The web deployment descriptor is loaded and parsed when the web container is first started. By default, changes to the descriptor are not detected and reloaded while the container is running. In fact, not many containers even provide this functionality - it's typically not a wanted feature, due to the possible security issues involved. The Struts configuration files also are loaded and parsed when the container is launched, and changes to these configuration files also are not automatically detected ; the same security issues are present.

Some applications might require the ability to reload the Struts configuration files without restarting the web container. If your application is one of them, there are ways you can do this. One approach is to create a Struts action that will reinitialize the ActionServlet (you may want to restrict which users can call this action). Once the ActionServlet is reinitialized, everything will be new and the application can again service requests , just like before.

A second strategy is to create a thread that monitors the lastModifiedTime of the configuration file. It can sleep for a few seconds and, upon awakening, compare the lastModifiedTime of the file against the one stored in a variable. If they are different, the file has changed and it's time to reload the application. This approach is nice because you don't have to worry about an unwelcome user reloading your application. However, the time that it gets reloaded is entirely up to the thread.