Component module

Recommended Plugin Module Type

The Component plugin module described below is available to OSGi-based plugins using version 2.x of the Atlassian Plugin Framework, supported in Confluence 2.10 and later.

We recommend that you use the new plugin module type described below, rather than the old-style Component and Spring Component module types. Confluence still supports the earlier module types, but the new OSGi-based plugin framework fixes a number of bugs and limitations experienced by the old-style plugin modules.

Purpose of this Module Type

Component plugin modules enable you to share Java components between other modules in your plugin and optionally with other plugins in the application. You can use it to make any type of class instance available to other plugins or modules. It's in effect a Spring bean declaration (with greatly simplified syntax, since only autowiring is supported) plus an OSGi export.

The typical uses of a component are:

• To define a singleton class that's used internally by your plugin, which the framework instantiates for you and passes to your other classes via autowiring; or
• To expose an API to other plugin modules.

Configuration

The root element for the Component plugin module is component. It allows the following attributes and child elements for configuration:

Attributes

1
2
<component-import
  key="appProps"
  interface="com.atlassian.sal.api.ApplicationProperties"/>

1
2
<component-import
  key="appProps"
  interface="com.atlassian.sal.api.ApplicationProperties"/>

*key attribute is required.

Elements

1
2
<component-import
  key="dictionaryService"
  interface="com.myapp.DictionaryService"
  filter="(language=English)" />

Example

Here is an example atlassian-plugin.xml file containing a single public component:

1
2
<atlassian-plugin name="Hello World" key="example.plugin.helloworld" plugins-version="2">
    <plugin-info>
        <description>A basic component module test</description>
        <vendor name="Atlassian Software Systems" url="http://www.atlassian.com"/>
        <version>1.0</version>
    </plugin-info>

    <component key="helloWorldService" class="com.myapp.DefaultHelloWorldService">
        <description>Provides hello world services.</description>
        <interface>com.myapp.HelloWorldService</interface>
    </component>
</atlassian-plugin>

Here is an example public component with several service properties:

1
2
<component key="dictionaryService" class="com.myapp.DefaultDictionaryService" interface="com.myapp.DictionaryService">
    <description>Provides a dictionary service.</description>
    <service-properties>
        <entry key="language" value="English" />
    </service-properties>
</component>

Notes

Some information to be aware of when developing or configuring a Component plugin module:

• Components, at installation time, are used to generate the atlassian-plugins-spring.xml Spring Framework configuration file, transforming Component plugin modules into Spring bean definitions. The generated file is stored in a temporary plugin jar and installed into the framework. The plugin author should very rarely need to override this file.
• The injection model for components first looks at the constructor with the largest number of arguments and tries to call it, looking up parameters by type in the plugin's bean factory. If only a no-arg constructor is found, it is called then Spring tries to autowire the bean by looking at the types used by setter methods. If you wish to have more control over how your components are created and configured, you can create your own Spring configuration file, stored in META-INF/spring in your plugin jar.
• If the public attribute is set to 'true', the component will be turned into an OSGi service under the covers, using Spring Dynamic Modules to manage its lifecycle.
• This module type in non-OSGi (version 1) plugins supported the StateAware interface in some products to allow a component to react to when it is enabled or disabled. To achieve the same effect, you can use the two Spring lifecycle interfaces: InitializingBean and DisposableBean. The init() and destroy() methods on these interfaces will be called when the module is enabled or disabled, exactly like StateAware. Making this change to a component in an existing plugin will be backwards compatible in all but JIRA. That is, a component module in a legacy plugin which implements InitializingBean will have its init() method called when it is enabled, exactly the same as such a component in an OSGi plugin.
• Components for non-OSGi (version 1) plugins behave very differently to components for OSGi plugins. For version 1 plugins, components are loaded into the application's object container, be it PicoContainer for JIRA or Spring for all other products that support components. For OSGi plugins, components are turned into beans for the Spring bean factory for that specific plugin. This provides more separation for plugins, but means you cannot do things like override JIRA components in OSGi plugins, as you can for static plugins.

Accessing Your Components

Accessing your components from within other plugin modules is extremely simple. All plugin modules in OSGi plugins are autowired. So to access a component, you need to add a Java setter method to your plugin module class.

For example, if you wanted to use the above helloWorldService component in an event listener module, you would add a field for the component and a setter method to the listener class as follows:

1
2
public class MyEventListener implements EventListener {
    private HelloWorldService helloWorldService;

    // ...

    public void setHelloWorldService(HelloWorldService helloWorldService) {
        this.helloWorldService = helloWorldService;
    }
}

Note that to access components in other plugins, the module needs to be marked as 'public' (as covered above) and imported into your plugin using a component-import.

RELATED TOPICS

Writing Confluence Plugins
Installing a Plugin
Information sourced from Plugin Framework documentation