CronTrigger itself is already property based but lacks sensible defaults. This class uses the Spring object name as job name, the Quartz default group ("DEFAULT") as job group, the current time as start time, and indefinite repetition, if not specified.

This class will also register the trigger with the job name and group of a given . This allows to automatically register a trigger for the corresponding JobDetail, instead of registering the JobDetail separately.

SchedulerFactoryObject will auto-detect Triggers that implement this interface and register them for the respective JobDetail accordingly.

The alternative is to configure a Trigger for a Job name and group: This involves the need to register the JobDetail object separately with SchedulerFactoryObject.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Invoked after population of normal object properties but before an init callback like 's method or a custom init-method.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Note: When using persistent Jobs whose JobDetail will be kept in the database, do not put Spring-managed objects or an ApplicationContext reference into the JobDataMap but rather into the SchedulerContext.

Normally this call will be used to initialize the object.

Invoked after population of normal object properties but before an init callback such as 's or a custom init-method. Invoked after the setting of any 's property.

In case of a QuartzJobObject, the reference will be applied to the Job instance as object property. An "applicationContext" attribute will correspond to a "setApplicationContext" method in that scenario.

Note that ObjectFactory callback interfaces like IApplicationContextAware are not automatically applied to Quartz Job instances, because Quartz itself is responsible for the lifecycle of its Jobs.

Note: When using persistent job stores where JobDetail contents will be kept in the database, do not put an IApplicationContext reference into the JobDataMap but rather into the SchedulerContext.

Operations performed by this JobStore will properly participate in any kind of Spring-managed transaction, as it uses Spring's DataSourceUtils connection handling methods that are aware of a current transaction.

Note that all Quartz Scheduler operations that affect the persistent job store should usually be performed within active transactions, as they assume to get proper locks etc.

For example, let's assume that the JobDataMap contains a key "myParam" with value "5": The Job implementation can then expose a object property "myParam" of type int to receive such a value, i.e. a method "setMyParam(int)". This will also work for complex types like business objects etc.

Note: The QuartzJobObject class itself only implements the standard Quartz IJob interface. Let your subclass explicitly implement the Quartz IStatefulJob interface to mark your concrete job object as stateful.

Derived from ArgumentConverting MethodInvoker to share common properties and behavior with MethodInvokingFactoryObject.

Supports both concurrently running jobs and non-currently running ones through the "concurrent" property. Jobs created by this MethodInvokingJobDetailFactoryObject are by default volatile and durable (according to Quartz terminology).

NOTE: JobDetails created via this FactoryObject are not serializable and thus not suitable for persistent job stores. You need to implement your own Quartz Job as a thin wrapper for each case where you want a persistent job to delegate to a specific service method.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Derives from ArgumentConvertingMethodInvoker, inheriting common configuration properties from MethodInvoker.

Useful to generically encapsulate a method invocation as timer task for java.util.Timer, in combination with a DelegatingTimerTask adapter. Can also be used with JDK 1.5's java.util.concurrent.Executor abstraction, which works with plain Runnables.

Extended by Spring's MethodInvokingTimerTaskFactoryObject adapter for TimerTask. Note that you can populate a ScheduledTimerTask object with a plain MethodInvokingRunnable instance as well, which will automatically get wrapped with a DelegatingTimerTask.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Allows registration of JobDetails, Calendars and Triggers, automatically starting the scheduler on initialization and shutting it down on destruction. In scenarios that just require static registration of jobs at startup, there is no need to access the Scheduler instance itself in application code.

For dynamic registration of jobs at runtime, use a object reference to this SchedulerFactoryObject to get direct access to the Quartz Scheduler (). This allows you to create new jobs and triggers, and also to control and monitor the entire Scheduler.

Note that Quartz instantiates a new Job for each execution, in contrast to Timer which uses a TimerTask instance that is shared between repeated executions. Just JobDetail descriptors are shared.

When using persistent jobs, it is strongly recommended to perform all operations on the Scheduler within Spring-managed transactions. Else, database locking will not properly work and might even break.

The preferred way to achieve transactional execution is to demarcate declarative transactions at the business facade level, which will automatically apply to Scheduler operations performed within those scopes. Alternatively, define a TransactionProxyFactoryObject for the Scheduler itself.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Note: When using persistent Jobs whose JobDetail will be kept in the database, do not put an IApplicationContext reference into the JobDataMap but rather into the SchedulerContext.

In case of a QuartzJobObject, the reference will be applied to the Job instance as object property. An "applicationContext" attribute will correspond to a "setApplicationContext" method in that scenario.

Note that ObjectFactory callback interfaces like IApplicationContextAware are not automatically applied to Quartz Job instances, because Quartz itself is reponsible for the lifecycle of its Jobs.

Default is Spring's , which supports standard Quartz instances. Note that this default only applies to a local Scheduler, not to a RemoteScheduler (where setting a custom JobFactory is not supported by Quartz).

Specify an instance of Spring's here (typically as an inner object definition) to automatically populate a job's object properties from the specified job data map and scheduler context.

Note: If this is set, the Quartz settings should not define a job store "dataSource" to avoid meaningless double configuration.

A Spring-specific subclass of Quartz' JobStoreSupport will be used. It is therefore strongly recommended to perform all operations on the Scheduler within Spring-managed transactions. Else, database locking will not properly work and might even break (e.g. if trying to obtain a lock on Oracle without a transaction).

Invoked after population of normal object properties but before an init callback like 's method or a custom init-method.

Normally this call will be used to initialize the object.

Invoked after population of normal object properties but before an init callback such as 's or a custom init-method. Invoked after the setting of any 's property.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

SimpleTrigger itself is already a PONO but lacks sensible defaults. This class uses the Spring object name as job name, the Quartz default group ("DEFAULT") as job group, the current time as start time, and indefinite repetition, if not specified.

This class will also register the trigger with the job name and group of a given . This allows to automatically register a trigger for the corresponding JobDetail, instead of registering the JobDetail separately.

This method allows the object instance to perform the kind of initialization only possible when all of it's dependencies have been injected (set), and to throw an appropriate exception in the event of misconfiguration.

Please do consult the class level documentation for the interface for a description of exactly when this method is invoked. In particular, it is worth noting that the and callbacks will have been invoked prior to this method being called.

Invoked after population of normal object properties but before an init callback like 's method or a custom init-method.