| Home >> All >> org >> [ quartz Javadoc ] |
| • | org.quartz.core.* (8) | • | org.quartz.ee.* (7) | • | org.quartz.examples.* (17) |
| • | org.quartz.helpers.* (3) | • | org.quartz.impl.* (38) | • | org.quartz.jobs.* (7) |
| • | org.quartz.plugins.* (4) | • | org.quartz.simpl.* (7) | • | org.quartz.spi.* (7) |
| • | org.quartz.utils.* (10) | • | org.quartz.xml.* (4) |
• org.quartz: Javadoc index of package org.quartz.
Package Samples:
• org.quartz.impl.calendar: Contains implementations of the SchedulerFactory, JobStore, ThreadPool, and other interfaces required by the org.quartz.core.QuartzScheduler.
• org.quartz.core: The main package of Quartz , containing the client-side interfaces.
• org.quartz.plugins.xml
• org.quartz.plugins.management
• org.quartz.plugins.history
• org.quartz.xml
• org.quartz.utils.weblogic
• org.quartz.utils
• org.quartz.spi
• org.quartz.simpl
• org.quartz.jobs.ee.mail
• org.quartz.jobs.ee.jmx
• org.quartz.jobs.ee.ejb
• org.quartz.jobs
• org.quartz.impl.jdbcjobstore.oracle
• org.quartz.impl.jdbcjobstore
• org.quartz.impl
• org.quartz.helpers
• org.quartz.ee.servlet
• org.quartz.ee.jta
Classes:
• CronTrigger: A concrete Trigger that is used to fire a JobDetail at given moments in time, defined with Unix 'cron-like' definitions. For those unfamiliar with "cron", this means being able to create a firing schedule such as: "At 8:00am every Monday through Friday" or "At 1:30am every last Friday of the month". A "Cron-Expression" is a string comprised of 6 or 7 fields separated by white space. The 6 mandatory and 1 optional fields are as follows: Field Name Allowed Values Allowed Special Characters Seconds 0-59 , - * / Minutes 0-59 , - * / Hours 0-23 ...
• UICronTrigger: A concrete Trigger that is used to fire a Job at given moments in time, defined with Unix 'cron-like' definitions. What you should know about this particular trigger is that it is based on org.quartz.CronTrigger, but the the functionality to build the sets from a string are unused. Whereas CronTrigger would essentially deserialize by rebuilding the TreeSets from the cronExpression, this class does not have a cronExpression, and de/serializes the TreeSets in their entirety. This is because the TreeSets map directly to the Struts user interface for set selection, and no effort is made to write an ...
• LoggingJobHistoryPlugin: Logs a history of all job executions (and execution vetos) via the Jakarta Commons-Logging framework. The logged message is customizable by setting one of the following message properties to a String that conforms to the syntax of java.util.MessageFormat . JobToBeFiredMessage - available message data are: Element Data Type Description 0 String The Job's Name. 1 String The Job's Group. 2 Date The current time. 3 String The Trigger's name. 4 String The Triggers's group. 5 Date The scheduled fire time. 6 Date The next scheduled fire time. 7 Integer The re-fire count from the JobExecutionContext. The ...
• Scheduler: This is the main interface of a Quartz Scheduler. A Scheduler maintains a registery of JobDetail s and Trigger s. Once registered, the Scheduler is responible for executing Job s when their associated Trigger s fire (when their scheduled time arrives). Scheduler instances are produced by a SchedulerFactory . A scheduler that has already been created/initialized can be found and used through the same factory that produced it. After a Scheduler has been created, it must have its start() method called before it will fire any Job s. Job s are to be created by the 'client program', by defining a class ...
• LoggingTriggerHistoryPlugin: Logs a history of all trigger firings via the Jakarta Commons-Logging framework. The logged message is customizable by setting one of the following message properties to a String that conforms to the syntax of java.util.MessageFormat . TriggerFiredMessage - available message data are: Element Data Type Description 0 String The Trigger's Name. 1 String The Trigger's Group. 2 Date The scheduled fire time. 3 Date The next scheduled fire time. 4 Date The actual fire time. 5 String The Job's name. 6 String The Job's group. 7 Integer The re-fire count from the JobExecutionContext. The default message ...
• DirectSchedulerFactory: A singleton implementation of org.quartz.SchedulerFactory . Here are some examples of using this class: To create a scheduler that does not write anything to the database (is not persistent), you can call createVolatileScheduler : DirectSchedulerFactory.getInstance().createVolatileScheduler(10); // 10 threads * // don't forget to start the scheduler: DirectSchedulerFactory.getInstance().getScheduler().start(); Several create methods are provided for convenience. All create methods eventually end up calling the create method with all the parameters: public void createScheduler(String schedulerName, ...
• StdSchedulerFactory: An implementation of org.quartz.SchedulerFactory that does all of it's work of creating a QuartzScheduler instance based on the contenents of a Properties file. By default a properties file named "quartz.properties" is loaded from the 'current working directory'. If that fails, then the "quartz.properties" file located (as a resource) in the org/quartz package is loaded. If you wish to use a file other than these defaults, you must define the system property 'org.quartz.properties' to* point to the file you want. See the sample properties files that are distributed with Quartz for information about ...
• QuartzInitializerServlet: A Servlet that can be used to initialize Quartz, if configured as a load-on-startup servlet in a web application. You'll want to add something like this to your WEB-INF/web.xml file: <servlet> <servlet-name> QuartzInitializer </servlet-name> <display-name> Quartz Initializer Servlet </display-name> <servlet-class> org.quartz.ee.servlet.QuartzInitializerServlet </servlet-class> <load-on-startup> 1 </load-on-startup> <init-param> <param-name>config-file</param-name> <param-value>/some/path/my_quartz.properties</param-value> ...
• InterruptableJob: The interface to be implemented by Job s that provide a mechanism for having their execution interrupted. It is NOT a requirment for jobs to implement this interface - in fact, for most people, none of their jobs will. The means of actually interrupting the Job must be implemented within the Job itself (the interrupt() method of this interface is simply a means for the scheduler to inform the Job that a request has been made for it to be interrupted). The mechanism that your jobs use to interrupt themselves might vary between implementations. However the principle idea in any implementation should ...
• JMXInvokerJob: Generic JMX invoker Job. It supports any number or type of parameters to the JMX bean. The required parameters are as follows (case doesn't matter): JMX_OBJECTNAME This is the fully qualifed name of the object (ie in JBoss to lookup the log4j jmx bean you would specify "jboss.system:type=Log4jService,service=Logging" JMX_METHOD This is the method to invoke on the specified JMX Bean. (ie in JBoss to change the log level you would specify "setLoggerLevel" JMX_PARAMDEFS This is a definition of the parameters to be passed to the specified method and their corresponding java types. Each parameter definition ...
• ClusterTest: Used to test/show the clustering features of JDBCJobStore (JobStoreTX or JobStoreCMT). All instances MUST use a different properties file, because their instance Ids must be different, however all other properties should be the same. If you want it to clear out existing jobs & triggers, pass a command-line argument called "clearJobs". You should probably start with a "fresh" set of tables (assuming you may have some data lingering in it from other tests), since mixing data from a non-clustered setup with a clustered one can be bad. Try killing one of the cluster instances while they are running, ...
• StatefulJobTest: Demonstrates the behavior of StatefulJob s, as well as how misfire instructions affect the firings of triggers of StatefulJob s - when the jobs take longer to execute that the frequency of the trigger's repitition. While the example is running, you should note that there are two triggers with identical schedules, firing identical jobs. The triggers "want" to fire every 3 seconds, but the jobs take 10 seconds to execute. Therefore, by the time the jobs complete their execution, the triggers have already "misfired" (unless the scheduler's "misfire threshold" has been set to more than 7 seconds). ...
• InterruptableJobTest: Demonstrates the behavior of StatefulJob s, as well as how misfire instructions affect the firings of triggers of StatefulJob s - when the jobs take longer to execute that the frequency of the trigger's repitition. While the example is running, you should note that there are two triggers with identical schedules, firing identical jobs. The triggers "want" to fire every 3 seconds, but the jobs take 10 seconds to execute. Therefore, by the time the jobs complete their execution, the triggers have already "misfired" (unless the scheduler's "misfire threshold" has been set to more than 7 seconds). ...
• EJBInvokerJob: A Job that invokes a method on an EJB. Expects the properties corresponding to the following keys to be in the JobDataMap when it executes: EJB_JNDI_NAME_KEY - the JNDI name (location) of the EJB's home interface. EJB_METHOD_KEY - the name of the method to invoke on the EJB. EJB_ARGS_KEY - an Object[] of the args to pass to the method (optional, if left out, there are no arguments). EJB_ARG_TYPES_KEY - an Object[] of the args to pass to the method (optional, if left out, the types will be derived by calling getClass() on each of the arguments). The following keys can also be used at need: INITIAL_CONTEXT_FACTORY ...
• QuartzServer: Instantiates an instance of Quartz Scheduler as a stand-alone program, if the scheduler is configured for RMI it will be made available. The main() method of this class currently accepts 0 or 1 arguemtns, if there is an argument, and its value is "console" , then the program will print a short message on the console (std-out) and wait for the user to type "exit" - at which time the scheduler will be shutdown. Future versions of this server should allow additional configuration for responding to scheduler events by allowing the user to specify org.quartz.JobListener , org.quartz.TriggerListener ...
• JobExecutionContext: A context bundle containing handles to various environment information, that is given to a JobDetail instance as it is executed, and to a Trigger instance after the execution completes. JobExecutionContext s are also returned from the Scheduler.getCurrentlyExecutingJobs() method. These are the same instances as those past into the jobs that are currently executing within the scheduler. The exception to this is when your application is using Quartz remotely (i.e. via RMI) - in which case you get a clone of the JobExecutionContext s, and their references to the Scheduler and Job instances have been ...
• SimpleTimeBroker: The interface to be implemented by classes that want to provide a mechanism by which the org.quartz.core.QuartzScheduler can reliably determine the current time. In general, the default implementation of this interface ( SimpleTimeBroker - which simply uses System.getCurrentTimeMillis() )is sufficient. However situations may exist where this default scheme is lacking in its robustsness - especially when Quartz is used in a clustered configuration. For example, if one or more of the machines in the cluster has a system time that varies by more than a few seconds from the clocks on the other systems ...
• TimeBroker: The interface to be implemented by classes that want to provide a mechanism by which the org.quartz.core.QuartzScheduler can reliably determine the current time. In general, the default implementation of this interface ( org.quartz.simpl.SimpleTimeBroker - which simply uses System.getCurrentTimeMillis() )is sufficient. However situations may exist where this default scheme is lacking in its robustsness - especially when Quartz is used in a clustered configuration. For example, if one or more of the machines in the cluster has a system time that varies by more than a few seconds from the clocks ...
• JobSchedulingDataProcessor: Parses an XML file that declares Jobs and their schedules (Triggers). The xml document must conform to the format defined in "job_scheduling_data_1_0.dtd" or "job_scheduling_data_1_1.xsd" After creating an instance of this class, you should call one of the processFile() functions, after which you may call the getScheduledJobs() function to get a handle to the defined Jobs and Triggers, which can then be scheduled with the Scheduler . Alternatively, you could call the processFileAndScheduleJobs() function to do all of this in one step. The same instance can be used again and again, with the list ...
• StatefulJob: A marker interface for JobDetail s that wish to have their state maintained between executions. StatefulJob instances follow slightly different rules from regular Job instances. The key difference is that their associated JobDataMap is re-persisted after every execution of the job, thus preserving state for the next execution. The other difference is that stateful jobs are not allowed to execute concurrently, which means new triggers that occur before the completion of the execute(xx) method will be delayed.
• JobDetail: Conveys the detail properties of a given Job instance. Quartz does not store an actual instance of a Job class, but instead allows you to define an instance of one, through the use of a JobDetail . Job s have a name and group associated with them, which should uniquely identify them within a single Scheduler . Trigger s are the 'mechanism' by which Job s are scheduled. Many Trigger s can point to the same Job , but a single Trigger can only point to one Job .
• JobExecutionException: An exception that can be thrown by a Job to indicate to the Quartz Scheduler that an error occured while executing, and whether or not the Job requests to be re-fired immediately (using the same JobExecutionContext , or whether it wants to be unscheduled. Note that if the flag for 'refire immediately' is set, the flags for unscheduling the Job are ignored.
• JobRunShellFactory: Responsible for creating the instances of JobRunShell to be used within the QuartzScheduler instance. Although this interface looks a lot like an 'object pool', implementations do not have to support the re-use of instances. If an implementation does not wish to pool instances, then the borrowJobRunShell() method would simply create a new instance, and the returnJobRunShell method would do nothing.
• DriverDelegate: This is the base interface for all driver delegate classes. This interface is very similar to the org.quartz.spi.JobStore interface except each method has an additional java.sql.Connection parameter. Unless a database driver has some extremely-DB-specific requirements, any DriverDelegate implementation classes should extend the StdJDBCDelegate class.
| Home | Contact Us | Privacy Policy | Terms of Service |