12.4. Plugin Management¶
Some RTI services allows for custom behavior through the use of pluggable components or plugins . The type of plugins is described in Section 7. A plugin is represented as a top-level service-owned object whose main role is a factory of other pluggable components, which themselves are responsible for providing the user-defined behavior.
Figure 12.7 shows that for each class of pluggable
components there is a top-level object with the suffix
Plugin. This is the
object that the Service obtains at the moment of loading the plugin. Multiple
Plugin objects can be registered from the same class, each uniquely
identified by its registered name.
Figure 12.7 also shows that there are two mechanisms through which a Service obtains a plugin object: a shared library or the Service API. Both mechanisms are complementary and are described with more detail in the next sections.
12.4.2. Service API¶
The user provides the plugin object via the Service API, through one of the
attach_[class]_plugin() operations. Upon successful return of
the operation, the Service takes ownership of the plugin object and will
delete it on Service stop.
Plugin lifecycle goes as follows:
- User instantiates plugin objects and provides them to the Service through
attach_[class]_plugin()operation. This is allowed only before the Service starts.
- After start, the Service becomes the owner of the registered plugin objects, calls operations on the plugin objects as needed, and keeps them alive while the Service remains started.
- On stop, the Service deletes each registered plugin object by calling the class abstract deleter.