三. 监听 Job 事件
org.quartz.JobListener 接口包含一系列的方法，它们会由 Job 在其生命周期中产生的某些关键事件时被调用。JobListener 可用的方法显示在代码 7.1 中。
代码 7.1. org.quartz.JobListener 接口中的方法
|
1 2 3 4 5 6 7 8 |
public interface JobListener { public String getName(); public void jobToBeExecuted(JobExecutionContext context); public void jobExecutionVetoed(JobExecutionContext context); public void jobWasExecuted(JobExecutionContext context, JobExecutionException jobException); } |
第七章. 实现 Quartz 监听器
在某个所关注事件发生时，监听器提供了一种方便且非侵入性的机制来获得这一通知。Quartz 提供了三种类型的监听器：监听 Job 的，监听 Trigger 的，和监听 Scheduler 自已的。本章解释如何应用每一种类型来更好的管理你的 Quartz 应用，并获悉到什么事件正在发生。
一. 监听器作为扩展点
术语 "扩展点" 在软件开发中用于指示框架或应用的某个位置，在这一位置在创建者期望用户扩展或定制这一框架来适合于他们的需要。(你也将会听到 hook(钩子) 一词，是一样意思的) 阅读全文 >>
十二. 为 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 还是继续要两个数据源。 |
十. 使用数据库存储 Scheduler 信息
·加载 Job 到数据库中
在前面有一节，"使用内存存储 Scheduler 信息"，我们谈到关于在使用 RAMJobStore 时如何加载 Job 和 Trigger 信息到内存中。那么 Job 和 Trigger 又是如何加载到数据库中的呢？存在以下几个方法把 Job 信息存入到数据库：
· 在你的程序中加入 Job 信息
· 使用 JobInitializationPlugin
· 使用 Quartz Web 应用程序
我们在前面的 RAMJobStore 章节中讨论过前面两种途径。当它们用于 JDBC JobStore 时，并没有多大不同，只些许例外。首先，你需要知道，当使用这两个方法式，Job 信息是在数据库中的。甚至在你停止了程序后，这些信息仍然保留在数据库中。甚至是你不在你的程序中使用 JobInitializationPlugin 时，这些信息也还在数据库中。基于这一点，它是会从数据库中找寻 Job 信息。第八章涵盖了 JobInitializationPlugin 和常用的 Quartz 插件。 阅读全文 >>
八. 为 JobStroreTX 创建数据源
当使用持久性 JobStore 时，Quartz 需要一个数据源。数据源扮演着产生数据库连接工厂的角色。在 Java 中，所有的数据源要实现 java.sql.Datasource 接口。Quartz 自身并不提供 Datasource 的所有功能；它只代表了那一职责。默认的，Quartz 能使用另一开源的框架，叫做 Commons DBCP，或者可以通过 JNDI 查找应用服务器中定义的 DataSource。
DBCP 是一个 Jakarta Commons 项目，网址是 http://jakarta.apache.org/commons/dbcp。这个框架的二进制版包含在 Quartz 的发行版中，你应该把它加到你的 Quartz 应用中来。你还需要加入 Commons Pool 库，它也包含中 Quartz 发行版中，是 DBCP 要用到的。
使用 JobStoreTX 时，你必须在 quartz.properties 文件中指定 Datasource 属性。这允许 Quartz 为你创建并管理 Datasource。表 6.4 列示了使用 JobStoreTX 时需要的 Datasource 配置属性。 阅读全文 >>
七. 使用 JobStoreTX
我们首先要讨论的持久性 JobStore 是 JobStoreTX。名字中的 "TX" 代表着 "事物"。我们在前面提过，JobStoreTX 是设计用于想要 Quartz 来管理事物的环境中。例如，假如你正构建一个 J2EE 应用，并且不使用到应用服务器，如 WebLogic 或者 JBoss 等，那么 JobStoreTX 会是持久性 JobStore 正确的选择。
在之前章节中，我们看到配置 RAMJobStore 是多么的容易。我们提到 RAMJobStore 的其中一个优点就是易于配置。我们已经讨论过让数据库准备就绪该做的事情；现在我们讲述使 Quartz 应用支持 JDBC JobStore 需要对它配置些什么。 阅读全文 >>
四. 使用持久性的 JobStore
在很多方面，JobStore 有用内存来存储的，还有些使用某种能长期持久的方式来共享相拟的特征。这不该有什么惊奇的，因为他们都服务于同一目的。
和 RAMJobStore 一样，特久性的 JobStore 有优点也有其缺点。在你选择持久性的 JobStore 之前应该认真理解其利与弊。这节就来解释它们的区别，以及在什么情况下你会希望使用持久性的 JobStore。
目前，Quartz 提供了两种类型的持久性 JobStore，每一种类型都有其独特的持久化机制。 阅读全文 >>
第六章. Job 存储和持久化
Quartz 用 JobStores 对 Job、Trigger、calendar 和 Schduler 数据提供一种存储机制。Scheduler 应用已配置的 JobStore 来存储和获取到部署信息，并决定正被触发执行的 Job 的职责。所有的关于哪个 Job 要执行和以什么时间表来执行他们的信息都来自于 JobStore。本章就来看 Quartz 中可用的各种类型的 JobStore，和如何使用他们，以及哪一个能适应你的需求。
| "罗马非一日建成" 道格拉斯.亚当斯，《宇宙环游指南》 |
一. Job 存储 阅读全文 >>
六. 介绍 Quartz Web 程序
早期的 Quartz 框架开发者意识到一个 GUI 对于某类用户群体是必需的。几年前，一个 Web 应用被创立，它可用于管理 Quartz 框架。虽说是历经了几年有相当投入的开发，但不得不说的，总是时断时续的。
近来出现有更多的要求对这个应用的更新与支持，因而又重新吸引了新的开发者自愿的工作并使之保持不断更新。这个应用就是知名的 Quartz Web 程序。(译者注：实际上这个应用程序基本驻步不前，当前版本还是 RC-1 2004-06-26 22:00 的，仅作参考来应用) 阅读全文 >>