Scheduled Quartz Job Plugin

Last Updated: Aug 8, 2019
documentation for the dotCMS Content Management System

This bundle plugin is an example of how to Schedule Quartz Jobs using an OSGi bundle plugin.

How to create a bundle plugin for Schedule Quartz Jobs

Let’s review the file organization on the Quartz Job (com.dotcms.job) example:

META-INF/MANIFEST.MF: The manifest file is very important for the deployment, it lists the Bundle Name, Version and Packages.

In this MANIFEST you must specify (see template plugin):

  • Bundle-Name: The name of your bundle
  • Bundle-SymbolicName: A short an unique name for the bundle
  • Bundle-Activator: Package and name of your Activator class (example: com.dotmarketing.osgi.job.Activator)
  • DynamicImport-Package: Dynamically add required imports the plugin may need without add them explicitly.
  • Import-Package: This is a comma separated list of package's name. List the packages that you are using insidethe bundle plugin and that are exported by dotCMS.

Beware ⚠️

In order to work inside the Apache Felix OSGi runtime, the importand export directive must be bidirectional.

dotCMS must declare the set of packages that will be available to the OSGi plugins by changing the file: dotCMS/WEB-INF/felix/osgi-extra.conf.

This is possible also using the dotCMS UI (System → Dynamic Plugins → Exported Packages).

Only after that exported packages are defined in this list, a plugin can Import the packages to use them inside the OSGi blundle.


Under the src folder you will find all the Java classes needed to create a dynamic Quartz Job in dotCMS:

$ pwd  
$ ls src/com/dotmarketing/osgi/job/

com.dotmarketing.osgi.job.CustomJob is a simple Job class that implements the regular Quartz Job interface.


This bundle activator extends from com.dotmarketing.osgi.GenericBundleActivator and implements BundleActivator.start().

Will manually register a CronScheduledTask making use of the method scheduleQuartzJob.

* PLEASE note the unregisterServices() call on the stop method, this call is MANDATORY (!) as it will allow us to stop and remove the register Quartz Job when the plugin is undeployed.


There are limitations on the hot deploy functionality for the OSGi Quartz Job plugin, once you upload this plugin you are limited on what code you can modify for the Quartz Job classes in order to see those changes the next time you upload the plugin.

This will apply only for the OSGi Quartz plugins, exactly to the Quartz Job class you implement and the classes use it by it, becausein order to integrate this plugin with the dotCMS/Quartz code we are using our plugin code outside the OSGi and the plugin context,trying to let know to dotCMS/Quartz that there is a Job outside its classpath trying to be use it and instantiate by them.

In order to support the use of the Quartz Jobs inside ours OSGi plugins we use the java hot swapping, it allows to redefine classes, unfortunately, this redefinition is limited only to changing method bodies:

The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance.

As long as you don’t add, remove or change methods (ONLY the methods bodies) for your Job code you will have an OSGi plugin thatwill reflect you changes when a redeploy is done. If you need to change the signature of the Job classes a restart of the dotCMS app will be require.

On this page


We Dig Feedback

Selected excerpt: