OpenCms-Struts Architecture

OpenCms-Struts has two clients and therefore two overlapping API's. The management API is the larger of the two and is used by OpenCms to manage the state of Struts applications. The second is the client API used by OpenCms developers to integrate Struts applications.

Management API

The management API is centered around the StrutsApplication object which acts like a finite state machine. StrutsApplication is an immutable object that has five states:

InActive : Used when there are errors while trying to move a Struts application to a new state or before a Struts application is to be deleted.

Initialized : Indicates the Struts application has a struts configuration file in the correct location and its synchronization directory exists.

Valid : Indicates the struts configuration file has been parsed and is valid.

Synchronized : Indicates the action resources declared in the struts configuration file have been synchronized with the file system.

Active : The Struts ActionServlet has been notified about the Struts application and is ready to accept client requests.

A StrutsApplication in one state can only move to one of two other states, with the exception of Inactive which can only move to Initialized. This relationship is described in the following directed graph.



A StrutsApplication can be in only one state at any given time, however the state accessor methods isInitialized, isValid, etc will return true if the Struts application is in a state higher in the heiarchy. That is a StrutsApplication in the Synchronized w ill return true to isVFSSync, isValid, and isInitialized. This is because a StrutsApplication that is in the Synchronized state must also be valid and initialized or else it could never reach the Synchronzied state as shown in the above graph.

As shown in the above graph a StrutsApplication in any state can be moved to the Inactive state. There are three scenarios when this would be done. The first is when a Struts application's struts-config.xml file has been changed and the Struts application needs to be updated. The second is before a Struts application is to be deleted it must be in the Inactive state. The final reason is when there is an error moving the Struts application from one state to another. For example if the synchronize directory has the wrong permissions the Struts application will fail to move to the Synchronized state. The StrutsApplication must be moved to an Inactive state, any errors must be corrected and the process must begin again by first moving the StrutsApplication to the Initialized state.

The StrutsApplication object is immutable, therefore thread safe. For each Struts application there exists a single valid StrutsApplication object, which is distributed via the CmsStruts object to any client requesting one. When a Struts application moves to a new state the old StrutsApplication object is invalidated, and any attempt to use an invalid StrutsApplication will result in a StrutsInvalidStateException to be thrown. Therefore StrutsApplication references should not be cached.

Visitors

OpenCms-Struts uses the Visitor pattern to perform state changes on the StrutsApplication object. The Visitor pattern allows new Visitors to be created without having to make changes to the StrutsApplication object. In order to move a StrutsApplication to a new state it must be passed an object that implements the Visitor interface. Visitor objects are passed to the StrutsApplication a ccept() method, which in turn passes itself to the Visitor's visit() method. The Visitor will then perform any neccessary actions and return a new StrutsApplication object that represents the new state of the Struts application. The new StrutsApplication will replace the old StrutsApplication, which will also be invalidated, in the CmsStruts hashmap.