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:
Quartz looks for all entries in the properties file that have the key:
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
#=============================================================== # Configure Main Scheduler Properties #=============================================================== org.quartz.scheduler.instanceName = QuartzScheduler org.quartz.scheduler.instanceId = AUTO #=============================================================== # Configure ThreadPool #=============================================================== org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 5 org.quartz.threadPool.threadPriority = 5 #=============================================================== # Configure JobStore #=============================================================== org.quartz.jobStore.misfireThreshold = 60000 org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore #=============================================================== # Configure Plugins #=============================================================== org.quartz.plugin.jobLoader.class = org.cavaness.quartzbook.chapter8.JobLoaderPlugin org.quartz.plugin.jobLoader.jobsDirectory = c:\quartz-book\sample\chapter8
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:
Looking back at Listing 8.3, you can see that our JobLoaderPlugin has this format:
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:
You can have as many properties as you need to configure your plug-in.
Plug In Properties Must Have set() Methods
You must provide a setXXX() method for each property you intend to pass to the plug-in class. Quartz throws a SchedulerException and halts the Scheduler if it can't find a public setXXX() method for the property. Based on the JavaBean specification, you should provide both get() and set() methods for the properties.
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.
Quartz Uses Introspection to Set Values
Quartz uses introspection and reflection to convert the parameter values in the quartz.properties file to their correct type in the plug-in class. You might have guessed that it uses the Common BeanUtils from Jakarata, but this isn't the case yet.
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
PrintInfoJob1 DEFAULT org.cavaness.quartzbook.chapter3.ScanDirectoryJob false false false SCAN_DIR c:quartz-bookinput1 trigger1 DEFAULT PrintInfoJob1 DEFAULT 2005-07-30T16:04:00 -1 10000
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
PrintInfoJob2 DEFAULT org.cavaness.quartzbook.chapter3.ScanDirectoryJob false false false SCAN_DIR c:quartz-bookinput2 trigger2 DEFAULT PrintInfoJob2 DEFAULT 2005-07-30T16:04:00 -1 60000
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.
Scheduling in the Enterprise
Getting Started with Quartz
Cron Triggers and More
JobStores and Persistence
Implementing Quartz Listeners
Using Quartz Plug-Ins
Using Quartz Remotely
Using Quartz with J2EE
Quartz and Web Applications
Using Quartz with Workflow
Appendix A. Quartz Configuration Reference