Component Plugin Module

Plugin Framework 2 only The Component plugin module described below is available only for OSGi-based plugins using version 2 of the Plugin Framework. In version 1 dynamic plugins or those deployed in WEB-INF/lib, this plugin module will be interpreted differently based on the application to which the plugin is deployed because it installs the component in the application's object container. JIRA, for example, uses Pico and Confluence uses Spring, so the object's lifecycle and dependency injection process will vary. For version 2 plugins, on the other hand, the internal Spring framework is used regardless of the host application, so creation, dependency injection, and sharing between plugins is consistent. Therefore, this plugin module in version 1 plugins will differ significantly from the information on this page.

On this page:

Purpose of this Module Type

Component plugin modules enable you to share Java components between other modules in your plugin and with other plugins in the application.

Configuration

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

Attributes

Name	Required	Description	Default
alias		The alias to use for the component when registering it in the internal bean factory.	The plugin key
class		The class which implements this plugin module. The class you need to provide depends on the module type. For example, Confluence theme, layout and colour-scheme modules can use classes already provided in Confluence. So you can write a theme-plugin without any Java code. But for macro and listener modules you need to write your own implementing class and include it in your plugin. The Java class of the component. This does not need to extend or implement any class or interface.
key		The identifier of the plugin module. This key must be unique within the plugin where it is defined. Sometimes you will need to uniquely identify a module. Do this with the module complete key. A module with key fred in a plugin with key com.example.modules will have a complete key of com.example.modules:fred. I.e. the identifier of the component.	N/A
public		Indicates whether this component should be made available to other plugins via the Component Import Plugin Module or not.	false

Elements

Example

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

<atlassian-plugin name="Hello World" key="example.plugin.helloworld" pluginsVersion="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>

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.

RELATED TOPICS

Plugin Module Types