Quartz Framework Quick Start (ii)--put the job into the configuration file

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

• Configuring quartz.properties files

The file quartz.properties defines the runtime behavior of the quartz application and includes many properties that control the operation of the quartz. This file should be placed in the path referred to by classpath, such as our Java project, and put it together with the jobs.xml described below in the project root directory is. If you're not sure, check out the. classpath file, which is configured with the classpath of your project.

Let's take a look at the most basic quartz.properties file and discuss some of these settings. Below is a trimmed 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 instance name (instancename) and the instance ID (instanceId) of the scheduler, respectively. The Org.quartz.scheduler.instanceName property 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 Chapter 11th, "Quartz clusters"). Now, set the following string: Org.quartz.scheduler.instanceName = Quartzscheduler
In fact, this is also the default value when you do not have the property configured.

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 across all scheduler instances, especially in a cluster. If you want Quartz to help you generate this value, you can set it 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 hostname plus the current date and time. In most cases, it is set to AUTO.
• Thread pool Properties

The next part 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 handle, the more worker threads you will need. The value of ThreadCount is at least 1. Quartz does not qualify you to set the maximum worker thread, but it can be quite impractical to set this value above 100 on most machines, especially if your Job executes for a long time. This does not have a default value, so you must set a value for this property.

The ThreadPriority property sets the worker thread's priority. Threads with high priority are executed more preferentially than those with lower levels. The maximum value of the ThreadPriority property is constant Java.lang.Thread.MAX_PRIORITY, which is 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, set it to 5, which is also not the default value for the property specified.

The last thread pool property to set is Org.quartz.threadPool.class. This value is a fully-restricted name for 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 a simple behavior and has been well tested. It provides a fixed-size thread pool in the scheduler's life cycle. You can create your own thread pool implementations on demand, and you might need to do this if you want an on-demand, scalable thread pool. This property has no default value and you must specify a value for it.

• Job Storage Settings

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

Storing the 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 make the Job stored in memory, you need to set the Org.quartz.jobStrore.class property to Org.quartz.simpl.RAMJobStore. If we do not want to lose the scheduler's state information 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," mentions 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 plugin you want to use. Plugins are often used on other open source frameworks, such as the Apache Struts framework (see http://struts.apache.org/).

One way to declaratively extend a framework is to implement a class that implements the Org.quartz.spi.SchedulerPlugin interface by adding new implementations. There are three methods that are called to the scheduler in the Schedulerplugin interface.

To configure the scheduler information declaratively in our example, we will use a plugin called Org.quartz.plugins.xml.JobInitializationPlugin that Quartz comes with.

By default, the plugin searches for files named Quartz_jobs.xml in Classpath and loads Job and Trigger information from it. The Quartz_jobs.xml file is discussed in the following section, which is an informal Job definition file that we refer to.

• Modify the quartz.properties configuration for the plugin

Jobinitializationplugin find Quartz_jobs.xml to get the JOB information for the statement. If you want to change this file name, you need to modify quartz.properties to tell the plugin to load that 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 property 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, under Classpath.

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

The following is the directory scan example of the JOB definition XML file. 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 >-1 </repeat-count >
< Repeat-interval >10000 </repeat-interval >
</Simple >
</Trigger >
</Job >
</Quartz >

The format of <start-time> in Jobs.xml is: < start-time >2008-09-03t14:43:00 </start-time >

where T separates the date and time, the default time zone
Or: < Start-time >2008-09-03t14:43:00+08:00 </start-time >

of which +08:00 said East eight district

The <job> element describes a job to register with the scheduler, which is equivalent to using the Schedulejob () method in the previous section. The two elements that you see in <job-detail> and <trigger> are the parameters that we pass to the method Schedulerjob () in the code. The front is essentially the same as here, but now is a more popular way of declaring it. The <trigger> element is also very intuitive: it uses the same properties as before, but it's easier to build a simpletrigger. So it's just a different (arguably and better) way of doing the same thing in the last piece of code. Obviously, you can also support more than one Job. In the previous code, the way we programmed it, we could support it declaratively.
<? 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 >scandirectory1 </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:\dyk\java\tomcat\conf </value >
</Entry >
</job-data-map > &nbs