Plugin FrameworkCST 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.
pluginstag 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
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
directory of the CST release.
Developers can choose how plugins are discovered by the application. They can set the
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
.batfiles 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
subclass of Java's
URLClassLoaderloads classes from jar files which appear in the
./lib/pluginsdirectory of the release.
When the new instances of the tools are created,
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
- parse the
class_nameproperty from a plugin description
- obtain the class for the class name using either the system class loader or
- use Java reflection to create an instance of the class using a constructor with no parameters.
- initialise the plugin through a call to 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
The class listens for when its own menu item is pressed. When users select the menu item,
GeneralPurposeMenuItem calls the
execute() method of
Author: Kevin Garwood