The Hackystat Framework is designed to support extension along many dimensions including modules, sensors, sensor data types, commands, documentation, and so forth. For each new functionality provided in Hackystat via these "extension points", Hackystat typically requires the developer to specify a definition file, in XML format, that provides information to the Framework about the specific extension implemented by the developer.

For example, in the case of a new command that should appear after logging in to the Hackystat server, the Framework needs to know the fully qualified classname corresponding to the servlet that will process the command, the classes implementing the selectors that enable the user to specify parameters to the command, and so forth. To tell the Framework this information, the developer of a new command provides along with its implementation an XML definition file. Furthermore, the developer must name it in a specific way so that the framework can find it at the appropriate time during the building of the system and/or during the startup of the server at run time.

While many extension points, such as sensors and sensor data types, are implemented in the "Core" subsystem modules, it is also possible to implement extension points in the "Application" subsystem modules. For example, the hackyApp_Pri module implements extension points for defining PRI indicators and PRI measures. The hackyApp_Sdsa application implements extension points for defining episode boundaries and processing rules.

Because the Hackystat build system typically gathers together these extension point definition files into one directory for ease of subsequent processing, they must be uniquely named. Otherwise, if two modules happen to create an extension point definition file with the same name, one of them will be overwritten by the other during the build of the system and functionality will be lost.

In order for the build system to automatically discover the set of extension point files, they must observe the following naming conventions. First, all extension point file names must have the ending ".def.xml". Please do not use this ".def.xml" file suffix unless the file defines an extension point. Second, different types of extension points are indicated by a unique prefix to this suffix. Thus, the extension point definition files for the "command" extension point end with ".command.def.xml", the XML definition files for the "daily analysis" extension point end with ".dailyanalysis.def.xml", and so forth.

To avoid the possibility of two extension point definition files from different modules having the same name, it is convention to use the Hackystat module name as a prefix. For example, the documentation definition file for the chapter on the Build System is defined in the hackyCore_Build module, and so this definition file is named "hackyCore_Build.buildsystem.docbook.def.xml".

The goals for this chapter are: (1) to provide a succint overview of all of the extension points available in this Hackystat configuration; and (2) to explicitly document the naming conventions for all extension point definition files to avoid potential file name collisions and simplify debugging.

The following sections of this chapter document the set of extension points to Hackystat as represented by their XML definition files.