What have you learned in this chapter? First, job chaining can be done with the Quartz framework. You can use either of the presented approaches, but the approach without the listener implementation probably will give you fewer
Finally, you should have learned that using OSWorkflow with Quartz is really pretty easy. All it takes is a few binaries, a few configuration files, and some workflow functions. Tie all that together with a workflow definition file, and off you go. Before you know it, you will have built a library of reusable functions and a bunch of workflows to run your business. Pretty soon, you'll have a nice little application that you can be proud of.
Appendix A. Quartz Configuration Reference
This appendix is designed to be used as a quick reference for configuring a Quartz application. Although this information is available in the Quartz documentation, this appendix provides a quicker way of looking up configuration properties and their possible values.
The Main Quartz Properties
Table A.1 lists the main scheduler properties. They are used to declare and identify the Scheduler and other top-level settings.
Table A.1. The Main Quartz Scheduler Properties
Each Quartz Scheduler must be identified by a given name. The name serves as a mechanism for client code to distinguish
Each Quartz Scheduler must be assigned a unique ID. The value can be any string but must be unique for all schedulers. You may use the value
if you want the ID to be generated for you. Starting with version 1.5.1, you can customize how instance IDs are automatically generated. See the
property, which is described
Starting with version 1.5.1, this property enables you to customize how instanceIDs are generated. This property can be used only if the property org.quartz.scheduler.instance-Id is set to AUTO . Defaults to org.quartz.simpl.SimpleInstanceIdGenerator , which generates an instance ID based on host name and time stamp.
This can be any String that is a valid name for a Java thread. If this property is not specified, the thread will receive the Scheduler's name ( org.quartz.scheduler.instanceName ) plus the appended string '_QuartzSchedulerThread' .
This property sets the amount of time in
This property sets the amount of time in milliseconds that the Scheduler will wait between retries when it has
This defaults to the most robust approach, which is to use the
This property is used to add a name-value pair that will be placed into the "Scheduler context" as strings. (see Scheduler.getContext()) . So for example, the setting org.quartz.context.key.MyEmail = myemail@somehostcom would perform the equivalent of scheduler.getContext().put("MyEmail"," email@example.com")
This should be set to the JNDI URL where Quartz can locate the application server's UserTransaction manager. The default value (if not specified) is java:comp/UserTransaction , which works for almost all application servers. Websphere users might need to set this property to jta/usertransaction . This is used only if Quartz is configured to use JobStoreCMT , and org.quartz.scheduler.wrapJobExecutionInUserTransaction is set to true .
Set this property to true if you want Quartz to start a UserTransaction before calling execute on your job. The transaction will commit after the job's execute method completes and after the JobDataMap is updated (if it is a StatefulJob ). The default value is false .
This is the class name of the JobFactory to use. The default is org.quartz.simpl.SimpleJobFactory . You can also try the value org.quartz.simpl.PropertySettingJobFactory . A job factory is responsible for producing instances of job classes. The SimpleJobFactory class calls newInstance() on the job class. The PropertySettingJobFactory also calls newInstance() but reflectively sets the job's bean properties using the contents of the JobDataMap .