第八章. 使用 Quartz 插件
Quartz 框架提供了几种用于扩展平台能力的方式。通过使用各种 "钩子" (通常指的就是扩展点)，Quartz 变得很容易被扩展和定制化来适应你的需要。其中一个最简单的扩展框架的方法就是使用 Quartz 插件。本章就来看看如何使用插件机制让 Quartz 进入到之前 Quartz 用户没去过的领域。
一. 什么是插件？
假如你使用过其他的开源框架，例如 Apache Struts，你应该已经熟悉了插件的概念和它们的用法。非常简单，一个 Quartz 插件就是一个实现了 org.quartz.spi.SchedulerPlugin 接口的 Java 类，并且被作为插件注册给了 Scheduler。这个插件接口包含了三个方法，显示在代码 8.1 中。 Read More- 八. 监听器中的线程使用
你看到了监听器接口中的方法后，你或许想知道是线程在调用监听器方法中饰演着什么样的角色。基实监听器方法是存在一个时序的，正如你看到方法名能想像到的那样。在一个 Job 执行的生命周期中，调用监听器方法以的顺序通常是固定的。图 7.2 描绘了监听方法的调用顺序和所涉及到的工作者线程。图 7.2. 监听器方法按某一特定的时序被调用
调用监听器方法的时序是固定的。如图 7.2 所示，在 Job 的执行前后，调用 Job 的 execute() 方法相同的线程被用于调用 JobListener 和 TriggerListener 的方法。假如你使用任何类类型的第三方线程管理工具或者打算实现你自己的线程池管理，知道这一点是很重要的。假如你在监听方法中实现了一个长运行逻辑时，这也会带来对性能上的负面影响。因为调用监听方法的线程和执行 Job 是同一个工作者线程，你不应该把监听方法实现的太复杂并要花费较长时间才能完成。保持它们的执行时间尽可能短。
Read More - 七. 在 quartz_jobs.xml 文件中实现监听器
本章的所有例子告诉了你如何以编程的方式设置监听器。假如我们一个关于在 quartz_jobs.xml 文件中以声明式配置监听器的例子都不提供本章就不能算是完结。
自 Quartz 1.5 开始，你能够在 Job 定义文件中指定监听器，当然就是知名的 quartz_jobs.xml 文件了。代码 7.14 显示了一个使用全局监听器的例子。
代码 7.14. Quartz 监听器能在 quartz_jobs.xml 文件中实现 Read More - 六. 使用 FileScanListener
Quartz 框架还包含一个我们未曾提及的监听器。这个监听器不像别的，因为它是为特定目的而设计的：同框架所带的一个工具 Job 一起用的。
这个监听器就是 org.quartz.jobs.FileScanListener 接口，它显式的设计为 FileScanJob 所用的，这一 Job 也在 org.quartz.jobs 包中。FileScanJob 检查某一指定文件的 lastModifiedDate。当某人改变了这个文件，这个 Job 就调用 FileScanListener 的 fileUpdated() 方法。
就像使用其他类型的 Quartz 监听器一样，你必须创建一个实现了 FileScanListener 接口的具体类。只有一个方法需要实现： Read More - 四. 监听 Trigger 事件
正如 JobListener, org.quartz.TriggerListener 接口也包含一系列给 Scheduler 调用的方法。然而，与 JobListener 有所不同的是， TriggerListener 接口还有关于 Trigger 实例生命周期的方法。代码 7.5 列出了 TriggerListener 接口的方法。
代码 7.5. org.quartz.TriggerListener 接口的方法 Read More - 三. 监听 Job 事件
org.quartz.JobListener 接口包含一系列的方法，它们会由 Job 在其生命周期中产生的某些关键事件时被调用。JobListener 可用的方法显示在代码 7.1 中。
代码 7.1. org.quartz.JobListener 接口中的方法1public interface JobListener { 2 public String getName(); 3 public void jobToBeExecuted(JobExecutionContext context); 4 public void jobExecutionVetoed(JobExecutionContext context); 5 6 public void jobWasExecuted(JobExecutionContext context, 7 JobExecutionException jobException); 8}
Read More - 第七章. 实现 Quartz 监听器
在某个所关注事件发生时，监听器提供了一种方便且非侵入性的机制来获得这一通知。Quartz 提供了三种类型的监听器：监听 Job 的，监听 Trigger 的，和监听 Scheduler 自已的。本章解释如何应用每一种类型来更好的管理你的 Quartz 应用，并获悉到什么事件正在发生。
一. 监听器作为扩展点
术语 "扩展点" 在软件开发中用于指示框架或应用的某个位置，在这一位置在创建者期望用户扩展或定制这一框架来适合于他们的需要。(你也将会听到 hook(钩子) 一词，是一样意思的) Read More - 十二. 为 JobStoreCMT 配置数据源
跟 JobStoreTX 一样，我们需要配置一个 Datasource 才能使用 JobStoreCMT。然而，JobStoreCMT 需要两个 Datasource 而不是像 JobStoreTX 只要一个。其中一个 Datasource 和我们为 JobStoreTX 设置的类同：作为不受管理的数据源。同时呢，我们还需配置第二个数据源，是作为受管理的数据源，它由应用服务器来进行管理。为什么 JobStoreCMT 需要两个 Datasource 呢？JobStoreCMT 的原始作者，Jeffrey Wescott，设计 JobStoreCMT 使用一个标准的 JDBC 连接来做它“自己的工作”，同时，代表客户端(如部署 Job) 的工作在执行时是使用一个在容器控制之下有自身事物的 JDBC 连接。即使 Quartz 处在一个大事物中，这种设计也允许用户与 Quartz 交互，而无需 JobStoreCMT 非得使用应用服务器的事物管理器(例如，经由 UserTransaction) 在做自己内部工作时(如处理已错过执行的 Trigger) 来创建和终止事物。如果是 JobStoreCMT 使用 UserTransation 只给它配置一个数据源，从配置方面来看确实方便。然而，在相比于别的特性需求和改进的必要性时，作此变化并不会成为团队中首要的问题，因而 JobStoreCMT 还是继续要两个数据源。
Read More - 十. 使用数据库存储 Scheduler 信息
·加载 Job 到数据库中
在前面有一节，"使用内存存储 Scheduler 信息"，我们谈到关于在使用 RAMJobStore 时如何加载 Job 和 Trigger 信息到内存中。那么 Job 和 Trigger 又是如何加载到数据库中的呢？存在以下几个方法把 Job 信息存入到数据库：
· 在你的程序中加入 Job 信息
· 使用 JobInitializationPlugin
· 使用 Quartz Web 应用程序
我们在前面的 RAMJobStore 章节中讨论过前面两种途径。当它们用于 JDBC JobStore 时，并没有多大不同，只些许例外。首先，你需要知道，当使用这两个方法式，Job 信息是在数据库中的。甚至在你停止了程序后，这些信息仍然保留在数据库中。甚至是你不在你的程序中使用 JobInitializationPlugin 时，这些信息也还在数据库中。基于这一点，它是会从数据库中找寻 Job 信息。第八章涵盖了 JobInitializationPlugin 和常用的 Quartz 插件。 Read More