Event Listener module
Job module
Language module
Macro Module
Servlet Filter module
Servlet module
Theme module
Web UI modules
Workflow module

Job module

Available:

From Confluence 2.2 to Confluence 5.9

Updated:

Job modules are auto-wired in Confluence 4.0.1 and later.

Status:Deprecated in Confluence 5.10 – use Job Config instead

Using job plugin modules, you can add repeatable tasks to Confluence, which are in turn scheduled by Trigger module.

Job plugin module

The Job plugin module adds a simple reusable component within a plugin. At a minimum, the module class must implement Quartz's Job interface, but for access to Confluence objects and database you should extend com.atlassian.quartz.jobs.AbstractJob. Jobs are scheduled with Trigger module

Configuration

In Confluence 4.0.1 and later, Jobs are autowired by Spring (see CONF-20162 for workarounds in earlier versions).

Here is a sample atlassian-plugin.xml fragment containing a single Job module:

1
2
<atlassian-plugin name="Sample Component" key="confluence.extra.component">
    ...
    <job key="myJob"
          name="My Job"
          class="com.example.myplugin.jobs.MyJob" perClusterJob="false" />
    ...
</atlassian-plugin>
  • The name attribute represents how this component will be referred to in the Confluence interface.
  • The key attribute represents the internal system name for your Job. This is what the Trigger will refer to.
  • The class attribute represents the class of the Job to be created. The class must have a no-argument constructor, or it will not be able to be instantiated by Confluence.
  • The perClusterJob attribute, if set to true, indicates that this job will run only once when triggered in a cluster rather than once on every node.

For examples of how to schedule Jobs to be run, see Trigger module.

Transaction Management

Note that transaction management is not automatically applied when you extend com.atlassian.quartz.jobs.AbstractJob. The core Confluence services and managers are declaratively wrapped so individual calls to any of these services do not require you to perform explicit transaction management. However, you may need to manually wrap your job execution in a transaction if:

  • You are making use of your own components which are not declaratively wrapped in a transaction via Spring configuration.
  • You are sharing data between a number of different calls to one or more services

To programmatically wrap in a transaction in your plugin you should first import the SAL transaction template.

  1. In your atlassian-plugin.xml include this:

    1
    2
    <component-import name="SAL Transaction Template" key="transactionTemplate">
        <interface>com.atlassian.sal.api.transaction.TransactionTemplate</interface>
    </component-import> 
    
  2. Import the following classes:

    1
    2
    import com.atlassian.sal.api.transaction.TransactionCallback;
    import com.atlassian.sal.api.transaction.TransactionTemplate;
    
  3. Enable your job to be auto-wired via the constructor and wrap your execution in a transaction as shown:

    1
    2
    public class MyJob
    {
        private final TransactionTemplate transactionTemplate;
    
    
        public MyJob(final TransactionTemplate transactionTemplate)
        {
            this.transactionTemplate = transactionTemplate;
        }
     
        void performOperation()
        {   
            return transactionTemplate.execute(new TransactionCallback<T>()
            {
                @Override
                public T doInTransaction()
                {
                    // work goes here
                }
            });
        }
    
        ...
    

Do not implement a single transaction that spans the work of a long-lived job. This could impact the availability of the Confluence service.

(You can follow the discussion on automatic transaction management in jobs on CONF-35465).

Rate this page: