sipxportlib
Version 3.3
|
#include <Plugin.h>
Public Types | |
typedef Plugin *(* | Factory) (const UtlString &pluginName) |
Public Member Functions | |
virtual | ~Plugin () |
The plugin destructor must be virtual. More... | |
virtual void | readConfig (OsConfigDb &configDb)=0 |
Read (or re-read) whatever configuration the plugin requires. More... | |
Protected Member Functions | |
Plugin (const UtlString &instanceName) | |
Derived constructors should be private so that only the Factory can call them. More... | |
Protected Attributes | |
UtlString | mInstanceName |
The instance name from the configuration directive - for logging and other identification. More... | |
A Plugin is a dynamically loaded object that is invoked by some component at some well defined time (it's an abstract class - how specific can the description be?).
This class is the abstract base from which all plugins must inherit; it decouples the configuration of what plugins should be invoked and the configuration parameters specific to each plugin from the program that uses them.
The following UML shows the relationships between the classes used to implement a plugin interface.
To define a plugin interface, a component creates a class derived from Plugin. This defines the interface(s) specific to the plugin; for example, in RegisterPlugin it defines a takeAction interface that allows each plugin to take some action when a REGISTER request is accepted.
The PluginHooks class is instantiated and its readConfig interface called by a the component to actually read what plugins have been configured for each class it defines that is derived from Plugin.
To actually invoke each configured plugin, the component instantiates a PluginIterator object on the PluginHooks object it configured, and then invokes the action interface using each Plugin object that it returns.
All Plugin classes must implement three methods to configure the plugin into the component:
Each class derived from Plugin should also define the method(s) that the program should invoke on the plugin, and all those methods must be virtual.
The Factory uses external C linkage to support dynamic loading of Plugin objects.
In addition to the class derived from this base, a plugin must implement a Factory routine with extern "C" linkage so that the OsSharedLib mechanism can look it up in the dynamically loaded library (looking up C++ symbols is problematic because of name mangling). The Factory routine looks like:
|
inlinevirtual |
The plugin destructor must be virtual.
Derived constructors should be private so that only the Factory can call them.
|
pure virtual |
Read (or re-read) whatever configuration the plugin requires.
configDb | a subhash of the individual configuration parameters for this instance of this plugin. |
|
protected |
The instance name from the configuration directive - for logging and other identification.