NDP Software 

Compelling Software • Design & Construction

Struts Config Xslt Tester (struts-config-verify.xsl)

Summary

Examines the struts-config.xml and looks for inconsistencies and reports the errors.

Motivation (The Problem)

The "path" attribute is inconsistent within the struts config. Sometimes you must include the ".do" extension, while sometimes you don't, depending on what element you are in. I found myself forgetting this periodically (during rigorous copy/paste sessions), causing extra build cycles. If you don't get it right, things just don't work during deployment, and there is no verification of this until you visit the page. These tests are easy to define, and therefore should be included as part of a struts deployment for everyone.

Usage

• First, before you even bother with this, get the struts-config.xml verifying against the DTD supplied by Apache. Although it beyond the scope of this document, the best place to do this is immediately within your editor. Most IDEs will do this if set up correctly. If you aren't using it, and don't have complete coverage testing, you will undoubtedly find some errors.
• Download here. (Either right click, or use "View Source" on the result.)
• Add a <style> task to your ant build file, which runs before your deployment - as early as possible, really. This can look like this:
  <style style="struts-config-verify.xsl"
in="struts-config.xml"
out="struts-config-errors.txt"/>
  The errors are routed to the given file, and are also send to the Xsl processor via the xsl:message element.
• Watch for and fix errors.
• Add new checks or send me ideas for them.

I maintain the copyright and all rights to this and derived works. At this point, all I ask is that you let me know if you find it useful, but I reserve the right to change this in the future.

Findings

Another motivation was to see if Xslt was a useful technology for such a test. I knew I wanted better validation of the struts-config.xml file, and considered adding it to the deployment code of struts. I looked at adding this non-invasively, but struts doesn't expose enough to allow such checks. I considered changing the code base, and had it on my task list. But then I realized it might be possible to express the tests concisely with Xslt, so I gave it a shot. I was pleasantly surprised, and wanted to share this technique with others.

Not exposed here, but perhaps interesting: I added more complicated tests appropriate for our own project (we have stricter rules about how struts-config.xml is used), and cross-reference it against another SiteMap file. This now enforces simple rules such as "if you add a page to the site map (menus), it must be set up in the struts-config.xml."

June 21, 2003

More thoughts

July 10, 2005

Although this was straightforward, bigger minds have come up with different solutions to this problem:

• Schematron - this is a cool little project where you express the rules you want to enforce and it generates an XSL that enforces the rules. The file it generates would undoubtedly be very close to what I built. I like the elegance of this solution, but haven't implemented it in a real system.
• RelaxNG or Schemas - this is the more traditional approach to this problem. There's something to be said about being "standard", and in this case that's about all there is to recommend this approach. Often the most appropriate choice.