Storing plugin settings

Plugin settings are part of the Shared Access Layer (SAL) component of the Atlassian plugin framework. Plugin settings provide a cross-product mechanism for persisting values relied upon by plugins.

PluginSettings objects are created with a PluginSettingsFactory, like this:

1
2
PluginSettings pluginSettings = pluginSettingsFactory.createGlobalSettings(); 

The PluginSettingsFactory interface includes the createGlobalSettings() method, which returns a PluginSettings object, as shown in the example.

Behind the scenes, settings are stored in a product-specific way. In a Confluence plugin, the pluginSettingsFactory will be a ConfluencePluginSettingsFactory and createGlobalSettings() will return a ConfluencePluginSettings object.

The ConfluencePluginSettings object uses Bandana internally to store the plugin settings. For a JIRA plugin, the JiraPluginSettingsFactory returns JiraPluginSettings objects that use PropertySets to store the settings.

Here is a diagram of SAL's plugin settings objects:

The PluginSettingsFactory uses the abstract factory pattern: it "provides an interface for creating families of related or dependent objects without specifying their concrete classes" (p. 87 in Design Patterns by Gamma et al).

The PluginSettingsFactory allows us to create specific PluginSettings objects for Confluence, JIRA, and other products depending on what type of PluginSettingsFactory (e.g. ConfluencePluginSettingsFactory) is in use, which depends on what product a plugin is for.

Plugin developers benefit from the use of the abstract factory pattern here in several ways. No matter what the target product for a plugin, one syntax can be used to interact with plugin settings. So it is not necessary for developers to learn and remember multiple, distinct settings storage syntax for different products. And a particular plugin could potentially have multiple target products without special handling, at least as far as plugin settings are concerned.

These are benefits often seen when using factories for object creation: users of the object are insulated from the specific objects used and their implementations, and maintenance changes only need to occur in one location rather than in each client.