Registering Your Plug-Ins

When a SchedulerFactory is first initialized, it searches the quartz.properties file for any Quartz plug-ins that you configured. It creates a new instance of the plug-in using the newInstance() method on java.lang.Class. Your plug-in must have a no-argument constructor, as the JobLoaderPlugin did in Listing 8.2.

To register your plug-in in the quartz.properties file, create a property in the quartz.properties file using the following format:

org.quartz.plugin..class=

Quartz looks for all entries in the properties file that have the key:

org.quartz.plugin..class

Then it attempts to create an instance of the class that is on the right side of the equals sign and assumes that it's a plug-in. You name the plug-in by providing a unique name in the field.

Listing 8.3 shows a quartz.properties file for use with the JobLoaderPlugin.

Listing 8.3. Register the JobLoaderPlugin in the quartz.properties File

You should have seen most of the settings in the quartz.properties file from Listing 8.3. The last section is where the JobLoaderPlugin is registered.

Specifying the Plug-In in quartz.properties

During initialization and startup, the Quartz Scheduler loads the properties from the quartz.properties file. You must follow a particular format when specifying plug-ins in the quartz.properties file. The format is shown here:

.<.class>=

• The is always org.quartz.plugin.
• The is a unique name that you assign.
• To specify the plug-in class, use the suffix .class.
• The right side is the fully qualified class name of the plug-in.

Looking back at Listing 8.3, you can see that our JobLoaderPlugin has this format:

org.quartz.plugin.jobLoader.class= org.cavaness.quartzbook.chapter8.JobLoaderPlugin

The name given to the plug-in is jobLoader and is arbitrary. We could have used any name, as long as it was unique from any other registered plug-in. On the right side of the equals sign, you must specify the fully qualified name of the plug-in class. This class must be in the classpath or available to the classloader.

Passing Parameters to the Plug-In

Most plug-ins require configuration values and, keeping with good programming practices, we don't want to have to hard-code these values into the plug-in class. Quartz provides a mechanism to pass parameter values to your plug-in class by providing these parameter values in the quartz.properties file.

The Scheduler finds all other properties that match a format of this:

..=

It treats them as JavaBean properties on the plug-in class. From Listing 8.3, this means that this property is turned into a setJobsDirectory() method call with the string value of c:\quartz-book\sample\chapter8 as a parameter for the method:

org.quartz.plugin.jobLoader.jobsDirectory= c:\quartz-book\sample\chapter8

You can have as many properties as you need to configure your plug-in.

The Quartz framework converts the property values to the type specified in the plug-in, assuming that it's a primitive type. For example, you can specify properties of type int and expect Quartz to convert the String from the quartz.properties file to an int. The framework, however, will not convert 1 to an integer class.

Creating the Job File for the JobLoaderPlugin

The JobLoaderPlugin looks for all XML files in the specified directory and assumes that each file is a valid Quartz jobs file. By "valid," we mean that the XML file adheres to the latest job-scheduling XSD file, which at the time of this writing is job_scheduling_data_1_5.xsd.

To make the JobLoaderPlugin more useful, we put each job, along with its job detail and trigger information, in a single XML file. This enables us to add and remove complete jobs just by putting the file into the directory or taking it out. This is very helpful in a development environment when you want to test only certain jobs. A single job XML file is shown in Listing 8.4.

Listing 8.4. A Job XML File Read by the JobLoaderPlugin

The job file is Listing 8.4 contains all the information necessary for the JobLoaderPlugin to schedule the job. This file also contains an entry for the JobDataMap, which is available to the job class at runtime. The example in Listing 8.4 uses a configured SimpleTrigger to schedule an infinitely repeating trigger that fires every 10 seconds. To further test the plug-in, we created a second job file, which differs from the first in some small way. Listing 8.5 shows the second job file.

Listing 8.5. A Second Job XML File Loaded by the JobLoaderPlugin

The second job file in Listing 8.5 differs only slightly from the one in Listing 8.4. We've changed the directory for the job, which is scanned and changed the trigger schedule. The point here is that you can have multiple jobs in the jobs directory, and the JobLoaderPlugin will load them all and schedule them individually with the Scheduler.