This Confluence has been LDAP enabled, if you are an ASF Committer, please use your LDAP Credentials to login. Any problems file an INFRA jira ticket please.

Child pages
  • CppBrokerStartPlugins
Skip to end of metadata
Go to start of metadata

The C++ broker automatically loads available plugins when it starts. It can get plugins from two places:

  1. All loadable plugins from the directory specified with the --module-dir option. This option has a platform-specific default which is used unless the --no-module-dir is specified.
  2. Individual plugins specified with the --load-module option

The broker will try to dynamically load shareable modules from the above locations. What actually registers the plugin with the Broker, though, is an action performed by the loaded module. Most (if not all) of the current plugins use a static instance of a class derived from qpid::Plugin. The object construction ends up calling the Plugin constructor which records the presence of the plugin.

There is no way to explicitly unload a plugin during execution. The scheme relies on process run-down unloading the dynamically loaded modules. However, there is a finalization procedure executed before the process runs down.

The C++ broker follows these basic steps at start time:

  • Load plugins (static initializers set up basic objects)
  • Broker calls qpid::Plugins::addOptions to add options from all plugins to the broker's option set. It does this by calling getOptions() on each known plugin instance. The qpid::Options-derived object is owned by the plugin and will be modified by option parsing.
  • Parse the argc/argv and config file options against the known option sets.
  • Call earlyInitialize(Target&) on each known plugin. Each plugin is expected to evaluate the type of the Target (by trying dynamic_cast on it) and only act on Target types it knows about. At this point the options have been parsed and are available.
  • Initiate recovery
  • Call initialize(Target&) on each known plugin.
  • Run