Plugin Framework

CST supports a plugin framework that allows projects to supplement the generic functionality of generated software tools with features from customised software components. Three types of plugins are supported in the Logging Tool:

import/export plugins - read and write repository data, appear in the Database menu.
subject information service plugins provide information about the current case study, appear in the Options menu.
report plugins generate graphs describing activity data, appear in the Reports menu.

Plugin are described in the plugins tag of the configuration file. CST uses the configuration file to create plugins and advertise them through specific menus. Please refer to Model Driven Development in the Presentation Layer for more information about how plugin attributes in the configuration file influence the generation of forms in the Logging Tool. This section of the design manual describes how plugins are supported in the architecture. Developers make plugin classes that implement either the GeneralPurposePluginAPI interface or the SubjectInformationServiceAPI interface.

Examples of the three types of plugins are included in the package cst.loggingTool.plugins.examples. The APIs allow plugins to access parts of the application through a SessionProperties object. The plugin examples show how the SessionProperties can be used to provide information to plugin code.

When developers finish making their plugin classes , they can package them in a jar file and put them in the ./lib/plugins directory of the CST release.

Developers can choose how plugins are discovered by the application. They can set the method setScanPlugins(...) in the class StartupOptions to achieve one of two actions:

plugins are detected by the System class loader. Choosing this option means that developers have to modify the class paths in the .bat files that appear in the release. If they are launching the tools from another program, then the classpath for invoking that application should have explicit references to the plugin jar files.
plugins are detected by the PluginClassLoader. This subclass of Java's URLClassLoader loads classes from jar files which appear in the ./lib/plugins directory of the release.

When the new instances of the tools are created, StartupOptions calls the ConfigurationManager to parse the configuration file. ConfigurationManager delegates the task of parsing plugin definitions to PluginManager. This class uses the plugin descriptions to create plugin instances. It achieves this through the following steps:

parse the class_name property from a plugin description
obtain the class for the class name using either the system class loader or the PluginClassLoader
use Java reflection to create an instance of the class using a constructor with no parameters.
initialise the plugin through a call to the initialise(...) method of GeneralPurposePluginAPI

The PluginManager maintains a collection of plugin objects that are later used to populate the Database, Filters and Reports menus in the Logging Tool. Each plugin is wrapped within an instance of GeneralPluginMenuItem. The class listens for when its own menu item is pressed. When users select the menu item, GeneralPurposeMenuItem calls the execute() method of GeneralPurposePluginAPI.

Author: Kevin Garwood