Quartz Framework Quick Start (ii)

Use declarative processing of software configurations as much as possible, followed by programmatic approaches. In the previous Quartz Framework QuickStart (a), if we were to change the execution time and frequency of the Job after it was started, we had to modify the source code recompile. This approach applies only to small example programs, but for a large and complex system, this becomes a problem. Therefore, if you can deploy the quart Job declaratively, and you need to allow it, you should choose this way every time

· Configuration quartz.properties file

File quartz.properties defines quartz application run-time behavior and includes many properties that control the operation of Quartz. This file should be placed under Classpath's path, such as our Java project, and put it in the project root directory along with the jobs.xml described below. If you're not clear, look at the. classpath file, which configures the classpath of your project.

Let's take a look at the most basic quartz.properties files and discuss some of these settings. Here is a trim version of the Quartz.propertis file #============================================================================
# Configure Main Scheduler Properties
#============================================================================
Org.quartz.scheduler.instanceName = Testscheduler
Org.quartz.scheduler.instanceId = AUTO
#============================================================================
# Configure ThreadPool
#============================================================================
Org.quartz.threadPool.class = Org.quartz.simpl.SimpleThreadPool
Org.quartz.threadPool.threadCount = 3
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.triggHistory.class = Org.quartz.plugins.history.LoggingJobHistoryPlugin
Org.quartz.plugin.jobInitializer.class = Org.quartz.plugins.xml.JobInitializationPlugin
Org.quartz.plugin.jobInitializer.fileNames = Jobs.xml
Org.quartz.plugin.jobInitializer.overWriteExistingJobs = True
Org.quartz.plugin.jobInitializer.failOnFileNotFound = True
Org.quartz.plugin.jobInitializer.scanInterval = 10
Org.quartz.plugin.jobInitializer.wrapInUserTransaction = False

· Scheduler Properties

The first section has two lines, setting the dispatcher's instance name (instancename) and the instance ID (Instanceid) respectively. Property Org.quartz.scheduler.instanceName can be any string you like. It is used to differentiate specific scheduler instances using multiple schedulers. Multiple schedulers are typically used in a clustered environment. (The Quartz cluster will be discussed in the 11th chapter, "Quartz cluster"). Now, set the following string on the line: Org.quartz.scheduler.instanceName = Quartzscheduler
In fact, this is also when you do not have this property configured when the default value.

The second property of the scheduler is org.quartz.scheduler.instanceId. As with the Instanename property, the Instanceid property also allows any string. This value must be unique among all scheduler instances, especially in a cluster. If you want Quartz to help you generate this value, you can set to AUTO. If the Quartz framework is running in a non-clustered environment, the automatically generated value will be non_clustered. If you are using Quartz in a clustered environment, this value will be the host name plus the current date and time. In most cases, set to AUTO.
· Thread Pool Properties

The next section is to set the necessary property values for the threads that are running in the background in the Quartz. The ThreadCount property controls how many worker threads are created to handle the Job. In principle, the more jobs you have to work with, the more worker threads you will need. The ThreadCount value is at least 1. Quartz does not qualify you to set the maximum number of worker threads, but setting the value above 100 on most machines can be quite impractical, especially if your Job execution time is longer. This item has no default value, so you must set a value for this property.

The ThreadPriority property sets the worker thread's priority. Higher-priority threads are executed more preferentially than lower-level threads. The maximum value for the ThreadPriority property is constant Java.lang.Thread.MAX_PRIORITY, equal to 10. The minimum value is constant Java.lang.Thread.MIN_PRIORITY, which is 1. The normal value of this property is Thread.norm_priority, which is 5. In most cases, it is set to 5, which is also the default value for which the property is not specified.

The last thread pool property to set is Org.quartz.threadPool.class. This value is a fully-restricted name of a class that implements the Org.quartz.spi.ThreadPool interface. Quartz's own thread pool implementation class is Org.quartz.smpl.SimpleThreadPool, which can meet the needs of most users. This thread pool implementation has simple behavior and is well tested. It provides a fixed size thread pool in the scheduler's lifecycle. You can create your own thread pool implementation as needed, perhaps if you want an on-demand scalable thread pool. This property has no default value and you must specify a value for it.

· Job Store Settings

The job Storage section's settings describe how job and Trigger information is stored during the life cycle of the scheduler instance. We haven't talked about the job store and its purpose, because the current example is not necessary, so we leave it to the future. Now, all you need to know is that we store scheduler information in memory rather than in a relational database.

Storing scheduler information in memory is very fast and easy to configure. When the scheduler process is terminated, all Job and Trigger status is lost. To keep the Job stored in memory, you need to set the Org.quartz.jobStrore.class property to Org.quartz.simpl.RAMJobStore. If we don't want the scheduler's state information to be lost after the JVM exits, we can use a relational database to store this information. This requires another job store (Jobstore) implementation, which we'll discuss later. The fifth chapter "Cron Trigger and Other" and chapter sixth "Job Storage and persistence" will mention the different types of job storage implementations you need to use.
· Plug-in Configuration

The last part of this simple quartz.properties file is the configuration of the quart plug-in you want to use. Plug-ins are often used in other open source frameworks, such as the Apache Struts framework (see http://struts.apache.org/).

One way to declare an extension framework is to implement the class of the Org.quartz.spi.SchedulerPlugin interface through a new addition. There are three methods that are called to the scheduler in the Schedulerplugin interface.

To declaratively configure scheduler information in our example, we use a Quartz called Org.quartz.plugins.xml.JobInitializationPlugin plug-in.

By default, the plug-in searches the classpath for a file named Quartz_jobs.xml and loads Job and Trigger information from it. The Quartz_jobs.xml file is discussed below, which is the informal Job definition file that we refer to.

· Modifying for Plug-ins quartz.properties Configuration

Jobinitializationplugin looking for Quartz_jobs.xml to get the declared Job information. If you want to change the file name, you need to modify quartz.properties to tell the plugin to load the file. For example, if you want Quartz to load Job information from an XML file named My_quartz_jobs.xml, you have to specify this file for the plug-in org.quartz.plugin.triggHistory.class = Org.quartz . plugins.history.LoggingJobHistoryPlugin
Org.quartz.plugin.jobInitializer.class = Org.quartz.plugins.xml.JobInitializationPlugin
Org.quartz.plugin.jobInitializer.fileNames = Jobs.xml
Org.quartz.plugin.jobInitializer.overWriteExistingJobs = True
Org.quartz.plugin.jobInitializer.failOnFileNotFound = True
Org.quartz.plugin.jobInitializer.scanInterval = 10
Org.quartz.plugin.jobInitializer.wrapInUserTransaction = False

We added the attribute org.quartz.plugin.jobInitializer.fileName and set the property value to the file name we want. This file name should be visible to ClassLoader, that is to say, under Classpath.

When the Quartz is started, read the Quartz.properties file, and then initialize the plug-in. It passes all the attributes configured above to the plugin, and the plugin is notified to search for different files.

The following is the XML file for the JOB definition of the directory scan example. As shown in the previous example, here we use a declarative approach to configure JOB and Trigger information. XML version= ' 1.0 ' encoding= ' utf-8 '?>
< quartz xmlns = "http://www.opensymphony.com/quartz/JobSchedulingData"
Xmlns:xsi = "Http://www.w3.org/2001/XMLSchema-instance"
Xsi:schemalocation = "Http://www.opensymphony.com/quartz/JobSchedulingData
Http://www.opensymphony.com/quartz/xml/job_scheduling_data_1_5.xsd "
Version = "1.5" >
< job >
< Job-detail >
< name > scandirectory </name >
< group > DEFAULT </Group >
< description >
A job that scans a directory for files
</Description >
< Job-class >
Com.vista.quartz.ScanDirectoryJob
</Job-class >
< volatility > False </volatility >
< durability > False </Durability >
< recover > False </recover >
< Job-data-map Allows-transient-data = "true" >
< entry >
< key > Scan_dir </key >
< value > D:/conf1 </value >
</Entry >
</Job-data-map >
</job-detail >

< trigger >
< simple >
< name > Scantrigger </name >
< group > DEFAULT </Group >
< Job-name > scandirectory </job-name >
< Job-group > DEFAULT </job-group >
< Start-time > 2008-09-03t14:43:00 </start-time >
<!--repeat indefinitely every seconds-->
< Repeat-count >