Community
Answers Developer Questions
Questions
Using Atlassian Events API to make a Listener in Bamboo

Using Atlassian Events API to make a Listener in Bamboo

While writing a Bamboo plugin, I need to handle the scenario where the plugin is enabled, disabled, uninstalled, etc. I was advised by an Atlassian employee in a previous question here that I should use the generic Atlassian Event API as it handles those events. I saw this post https://developer.atlassian.com/display/JIRADEV/Plugin+Tutorial+-+Writing+JIRA+event+listeners+with+the+atlassian-event+library that seemed to provide a great example, though handling Jira-specific events.

In my atlassian-plugin.xml file I declared this :

&lt;component-import key="eventPublisher" interface="com.atlassian.event.api.EventPublisher"/&gt;
   
    &lt;component key="eventListener" class="com.pronetbeans.bamboo.crontester.PluginStatusChangesListener"&gt;
        &lt;description&gt;Listens if a plugin throws an Event&lt;/description&gt;
    &lt;/component&gt;

Then my listener class :

public class PluginStatusChangesListener implements InitializingBean, DisposableBean {

    private static final Logger log = Logger.getLogger(PluginStatusChangesListener.class);
    private final EventPublisher eventPublisher;

    public PluginStatusChangesListener(EventPublisher eventPublisher) {
        log.info("\n\nPluginStatusChangesListener.PluginStatusChangesListener\n\n");
        this.eventPublisher = eventPublisher;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        log.info("\n\nPluginStatusChangesListener.afterPropertiesSet\n\n");
        eventPublisher.register(this);
    }

    @Override
    public void destroy() throws Exception {

        log.info("\n\nPluginStatusChangesListener.destroy\n\n");
        eventPublisher.unregister(this);
    }

    @EventListener
    public void onPluginDisabledEvent(PluginDisabledEvent event) {
        log.info("\n\nPluginStatusChangesListener.pluginDisabledEvent running...\n\n");
    }

}

After installing the plugin, dsabling, enabling it, disabling it, and uninstalling it,
the only methods that seemed to ever get called are the constructor, afterPropertiesSet, and
destroy. The annotated onPluginDisabledEvent method never seems to get called.

Is there something I'm missing in the setup?

3 answers

1 accepted

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

1 vote

Answer accepted

Hi Adam,

That documentation on the StateAware interface is accurate, but now quite a bit out of date. The com.atlassian.plugin.StateAware interface will only work with type 1 plugins and you can use InitialisingBean and DisposableBean to receive hooks when your plugin is started and stopped. In certain circumstances (if your plugin reads and writes from the PluginSettingsFactory during start-up), using InitialisingBean can cause database deadlocks - so you should actually prefer using com.atlassian.sal.api.lifecycle.LifecycleAware instead.

You can listen to some of the plugin framework events, but not all of them. For example, if you add a listener for the PluginFrameworkStartingEvent, your handler will never be invoked because this event is fired before your plugin is initialised. PluginFrameworkStartedEvent, however, should be fine.

In general, it is extremely difficult to write plugin code that can tell the difference between a plugin being disabled and a plugin being un-installed (and similarly between a plugin being installed for the first time and a plugin being initialised from a cold server start).

Confluence has a lifecycle module where you can listen for the parent application's lifecycle events (see https://developer.atlassian.com/display/CONFDEV/Lifecycle+Module), but I don't know if there is a similar facility in Bamboo. Even then, this method is unreliable and there are circumstances where the callbacks won't be fired.

For the installed vs. start-up case, the best hack for this I can think of is to just implement LifecycleAware and find someway to examine Bamboo's start-up timestamp. If the start-up was extremely recent, you can assume it's a cold start - if it was over ~1min ago, you can assume this is a fresh plugin install.

For the un-install vs. disabled case, there is really no way to handle this, since before un-installing, the plugin is always disabled first, and once your plugin is disabled, your code is completely unloaded. What are you hoping to achieve with this approach? It might be better to implement some administrative "clean-up" action that an administrator must manually invoke before un-installing your plugin.

Sorry to say that there are no easy answers here.