Application Control Infrastructure:

When a sandev deployment (like sand/deploy/TaskHeapDemo) is deployed into the container, the first call to the servlet creates the SandRoot, which loads the deployment configuration and initializes all NodeInstances declared to run on the current server. Each node does its own startup validation, with initial configuration data verified by the DataManager.

On startup, the SandRoot walks through the configuration NodeInstances, creating and initializing new Controllable nodes for each (typically this is done using an instance factory to initialize node data members). The node is given a reference to its NodeInstance, and then accessed as a Messageable and a Loggable to initialize those node mechanisms. Once all nodes have been started, the SandRoot provides runtime lookup and global control by operating directly on the instances it holds.

The ControlWrapper interface is used to adapt a specific control interface (such as JMX) to a node. A node can support multiple ControlWrappers simultaneously, and will notify all of them when its state changes. That allows a SandRoot to control a node without worrying about getting out of sync with any control displays, and it leaves the core node independent of any specific control technology.



WAR deployment:

For a self-contained WAR, the development environment defines SAND_WARFILE_DEPLOY as the directory where the resulting file should be placed. This overrides normal container deployment.

Following the TaskHeapDemo build as an example, here's how the resulting deployment WAR is created from the build result files:

At runtime, the controlling servlet makes a call to retrieve the UIFormOwner by node instance name. If the result is null, it looks for the presence of sandev/config.xml to see if it is running as part of a deployment WAR. If it is, then it creates a new instance of SandBossRoot and initializes the SingletonAccessor.