后来发现放在里面的这两个包是 tomcat5.5 的，是 JSP 2.0 规范的，而部署的服务器是 tomcat 6.0 是 JSP 2.1 规范的，两者可能有一定的冲突，才导致这样的错误。

　　工作流中有个这样的简单案例，当一笔单子金额大于 50万时，应该将任务分配给 Senior Agent 处理，否则交给 Junior Agent 处理，我们用 BeanShell 简单模拟这段脚本。

    public static void main(String[] args) throws Exception {
        Interpreter i = new Interpreter();
        i.set(”price”, 1000000);
        i.set(”user”, “”);
        i.eval(”if(price > 500000)\n” +
                “user = \”SeniorAgent\”;\n” +
                “else \n” +
                “user = \”JuniorAgent\”;”);
        System.out.println(i.get(”user”));
    } 

　　运行结果是打印出了：SeniorAgent

　　可以看出，BeanShell 用非常动态化的方式，完成了我们一个简单的案例的处理，这里，我们只需要将需要解析的 Java 语言的脚本交给 BeanShell 的 Interceptor，并把脚本中用到的参数值传入，就可以了，最后，我们把运算结果赋给一个变量，然后获取变量结果，就可以了。

　　看到 Developer Works 网站上有一篇 BeanShell 实现公式管理的文章：http://www.ibm.com/developerworks/cn/java/l-formula/index.html，可以参考一下。

From: http://www.steadyxp.com/archives/851.html

    } finally {

           if (method != null) {

              try {

                  method.releaseConnection();

              } catch (Exception e) {

                  logger.error("-------> Release HTTP connection exception:", e);

              }

           }

           if (client != null) {

              try {

                  ((SimpleHttpConnectionManager) client.getHttpConnectionManager()).shutdown();

              } catch (Exception e) {

                  logger.error("-------> Close HTTP connection exception:", e);

              }

              client = null;

           }

       }

　　其中一个主要的扩展点是针对 TaskNode 进行的用户的分配。TaskNode 是 jBPM 中一个非常重要的概念，一个任务节点可以包含若干个任务，不同的任务可以由不同的人来完成，任务实例被分配给 actorId 来完成，其中指定到人的分配工作就是 Assignment 要处理的，这也是我们需要定制的功能，为了实现用户的分配，我们需要实现 AssignmentHandler 接口，接口原型如下。

public interface AssignmentHandler extends Serializable {    
    void assign(Assignable assignable, ExecutionContext executionContext) throws Exception;
}

　　通常用代码实现的话，我们可以让一个类实现这个接口，并在 swimlane 或者 tasknode 中的 assignment 指定该类。但是，这样的灵活性是显然不够的，在系统的使用过程中，分配策略会不断的进行调整，因此我们需要更为灵活的解决方案，jBPM 本身可以使用基于 Bean Shell 的脚本来写分配策略，但是 Bean Shell 不是那么强大，我们需要更为强大的解决方案，因此，我们选用了已经被 JBoss 收为旗下的 JBoss Drools 4.0 规则引擎 (在 3.0 的时候曾经改名为 JBoss Rules，4.0 又改回来了)

　　完整版本请查看：http://www.steadyxp.com/archives/120.html

假设已设置如下变量或参数

• 挂接 Discuz! Passport 的应用程序假设为一套 PHP 语言编写的 CMS 系统
• Discuz! 的 URL 为 http://www.myforums.com
• 应用程序的 URL 为 http://www.mywebsite.com
• 应用程序的注册页面为 http://www.mywebsite.com/register.php
• 应用程序的登录页面为 http://www.mywebsite.com/login.php?action=login
• 应用程序的退出页面为 http://www.mywebsite.com/login.php?action=logout

开启通行证后的用户登录流程

• 如果用户在论坛点击“登录”，则转向到事先设置好的应用程序登录页面（http://www.mywebsite.com/login.php?action=login），并在登录页面的 URL 中加入参数 forward（加入 forward 后的链接例如 http://www.mywebsite.com/login.php?action=login&forward=http://www.myforums.com/index.php），用于在登录后将用户导向到指定的 URL。
  
  
• 应用程序收到此请求后，按照惯例生成表单，并增加一个表单变量，将 GET 方式传递过来的 forward 参数通过表单进行传递。
  
  
• 用户在应用程序的表单中填写登录信息，并提交到应用程序的登录验证程序。应用程序验证用户提交的用户名和密码的合法性：
  
  
  • 如果不通过：提示用户名密码错误，要求其返回上一页重新填写。
    
    
  • 如果通过，需要进行如下操作：
    
    
    • 设置自身 Cookie 或 Session，使得应用程序自身处于登录状态。
      
      
    • 检查表单中是否提交了 forward 变量，如有，则意味着登录请求可能是由论坛而来，将此变量传递到后面的请求中。如没有，自行生成 forward 变量，使得论坛登录后能够跳转回到应用程序中。
      
      
    • 通过 header('Location: http://www.myforums.com/api/passport.php?action=login&auth=xxx&forward=http://yyy&verify=zzz') 的方式，将登录请求传递到论坛进行处理。其中 auth 用来将用户信息与资料以特定的格式，加密传递给论坛，forward 用于告知论坛 Passport API 完成自身操作后转向到的 URL 地址，verify 用于验证前面两个变量的有效性。auth、forward、verify 格式与结构将在后面进行说明。
  
  
  
• Discuz! Passport API 在接收到由应用程序通过 header() 提交过来的请求后，进行如下操作：
  
  
  • 根据 verify 判断 auth 和 forward 变量是否合法，如合法则继续，否则终止。
    
    
  • 将 auth 根据既定算法解密，并还原成数组，数组的内容与格式将在后面进行说明。根据数组中的内容，检查此用户是否存在。如存在，则根据上述数组中的内容 UPDATE 论坛中相应的用户资料。如不存在，则使用数组中的信息 INSERT 到论坛用户资料表中。
    
    
  • 论坛设置 Cookie 或 Session，使得论坛自身处于登录状态。
    
    
  • 根据应用程序反馈的 forward 值，通过 header('Location: http://xxx') 的形式将页面跳转到 forward 变量指定的 URL。
  
  
  
• 至此，登录流程结束

开启通行证后的用户退出流程

• 如果用户在论坛点击“退出”，则转向到事先设置好的应用程序退出页面（http://www.mywebsite.com/login.php?action=logout），并在登录页面的 URL 中加入参数 forward（例如 http://www.mywebsite.com/login.php?action=login&forward=http://www.myforums.com/index.php），用于在退出后将用户导向到指定的 URL。
  
  
• 应用程序收到此请求后，清除自身 Cookie 或 Session，使得应用程序自身处于非登录状态。
  
  
• 检查是否提交了 forward 变量，如有，则意味着登录请求可能是由论坛而来，将此变量传递到后面的请求中。如没有，自行生成 forward 变量，使得论坛登录后能够跳转回到应用程序中。
  
  
• 通过 header('Location: http://www.myforums.com/api/passport.php?action=logout&forward=http://yyy&verify=zzz') 的方式，将退出请求传递到论坛进行处理。其中 forward 用于告知论坛 Passport API 完成自身操作后转向到的 URL 地址，verify 用于验证 forward 变量的有效性。forward、verify 格式与结构将在后面进行说明。
  
  
• Discuz! Passport API 在接收到由应用程序通过 header() 提交过来的请求后，进行如下操作：
  
  
  • 根据 verify 判断 forward 变量是否合法，如合法则继续，否则终止。
    
    
  • 清楚论坛的 Cookie 或 Session，使得论坛自身处于非登录状态。
    
    
  • 根据应用程序反馈的 forward 值，通过 header('Location: http://xxx') 的形式将页面跳转到 forward 变量指定的 URL。
  
  
  
• 至此，退出流程结束。

开启通行证后的用户注册流程

• 如果用户在论坛点击“注册”，则转向到事先设置好的应用程序注册页面（http://www.mywebsite.com/register.php），并在注册页面的 URL 中加入参数 forward（例如 http://www.mywebsite.com/register.php?forward=http://www.myforums.com/index.php），用于在注册后将用户导向到指定的 URL
  
  
• 应用程序收到此请求后，按照惯例生成表单，并增加一个表单变量，将 GET 方式传递过来的 forward 参数通过表单进行传递
  
  
• 用户在应用程序的表单中填写注册信息，并提交到应用程序的注册验证程序。应用程序验证用户提交信息的完整性和合法性：
  
  
  • 如果不通过：提示其问题所在，要求其返回上一页重新填写
    
    
  • 如果通过，需要进行如下操作：
    
    
    • 将用户资料插入到应用程序自身用户数据库中
      
      
    • 设置自身 Cookie 或 Session，使得应用程序自身处于登录状态
      
      
    • 检查表单中是否提交了 forward 变量，如有，则意味着注册请求可能是由论坛而来，将此变量传递到后面的请求中。如没有，自行生成 forward 变量，使得论坛注册后能够跳转回到应用程序中
      
      
    • 通过 header('Location: http://www.myforums.com/api/passport.php?action=login&auth=xxx&forward=http://yyy&verify=zzz') 的方式，将注册请求传递到论坛进行处理。其中 auth 用来将用户信息与资料以特定的格式，加密传递给论坛，forward 用于告知论坛 Passport API 完成自身操作后转向到的 URL 地址，verify 用于验证前面两个变量的有效性。auth、forward、verify 格式与结构将在后面进行说明
  
  
  
• Discuz! Passport API 在接收到由应用程序通过 header() 提交过来的请求后，进行如下操作：
  
  
  • 根据 verify 判断 auth 和 forward 变量是否合法，如合法则继续，否则终止
    
    
  • 将 auth 根据既定算法解密，并还原成数组，数组的内容与格式将在后面进行说明。根据数组中的内容，检查此用户是否存在。如存在，则根据上述数组中的内容 UPDATE 论坛中相应的用户资料。如不存在，则使用数组中的信息 INSERT 到论坛用户资料表中
    
    
  • 论坛设置 Cookie 或 Session，使得论坛自身处于登录状态
    
    
  • 根据应用程序反馈的 forward 值，通过 header('Location: http://xxx') 的形式将页面跳转到 forward 变量指定的 URL
  
  
  
• 至此，注册流程结束

  本部分中，加下划线显示的部分，是需要对您的应用程序进行更改的部分，事实上，这部分更改会非常容易和方便。

在进行 reschedule 操作的时候，我们通常只需要修改 Trigger 的时间，这时候我们只需要重新 new 一个含有新的 Schedule 时间的 Trigger 对象，reschedule 一下就可以了。

Unschedule
unscheduleJob(String triggerName, String groupName)

进行 unschedule 的时候，我们只需要知道名字和 group 就可以了。

进行 Schedule 操作前后，Database 中的相关数据都会被更改，在执行 unschedule 或者该 schedule 已经执行过，数据库中的 trigger 信息都会被删除。

在 Quartz 的应用中，我们用到了以下的一些东西，ScheduleFactory, Scheduler, Job, JobDetail, Trigger，简单说明一下他们的用途。

SchedulerFactory 是 Scheduler 的工厂，我们可以从中获得受工厂管理的 Scheduler 对象。

SchedulerFactory scheduleFactory = new StdSchedulerFactory();
Scheduler scheduler = scheduleFactory.getScheduler();

Scheduler 是一个计划集，其中可以包含多个 JobDetail 和 Trigger 组成的计划任务。
我们可以从 SchedulerFactory 中取得 Scheduler。

接口Job是每个业务上需要执行的任务需要实现的接口，该接口只有一个方法：

public interface Job {
    public void execute(JobExecutionContext context)
        throws JobExecutionException;
}

我们可以在里面定义我们的 Job 执行逻辑，比如清除过期数据，更新缓存等。

JobDetail描述了一个任务具体的信息，比如名称，组名等等。
JobDetail jobDetail = new JobDetail("SayHelloWorldJob", Scheduler.DEFAULT_GROUP, SayHelloWorldJob.class);
在上面的构造方法中，第一个是任务的名称，第二个是组名，第三个就是实际当任务需要执行的回调类。

Trigger顾名思义就是触发器，Quartz有个很好的想法就是分离了任务和任务执行的条件。Trigger就是控制任务执行条件的类，当Trigger认为执行条件满足的时刻，Trigger会通知相关的Job去执行。分离的好处是：
1.你可以为某个Job关联多个Trigger，其中任何一个条件满足都可以触发job执行，这样可以完成一些组合的高级触发条件
2.当Trigger失效后（比如：一个永远都不能满足的条件），你不必去声明一个新的job，代替的是你可以为job关联一个新的Trigger让job可以继续执行。

目前的Quartz实现中，存在两种Trigger,SimpleTrigger和CronTrigger,SimpleTrigger用来完成一些比如固定时间执行的任务，比如：从现在开始1分钟后等等；而CronTrigger(没错，和unix的cron进程的含意一样)用来执行calendar-like的任务，比如：每周五下午3：00，每月最后一天等等。

在我们项目中，都是一些固定时间的 Job，所以只用到了 SimpleTrigger。
Trigger trigger = new SimpleTrigger("SayHelloWorldJobTrigger",Scheduler.DEFAULT_GROUP,new Date(),null,0,0L);
这个构造方法中，第一个是Trigger的名称，第二个是Trigger的组名，第三个是任务开始时间，第四个是结束时间，第五个是重复次数（使用SimpleTrigger.REPEAT_INDEFINITELY常量表示无限次），最后一个是重复周期（单位是毫秒），那么这样就创建了一个立刻并只执行一次的任务。

但我们定义好了 JobDetail，Job，和 Trigger 后，就可以开始 Schedule 一个 Job 了。

scheduler.scheduleJob(jobDetail, trigger);

这条语句就是把job和Trigger关联，这样当Trigger认为应该触发的时候就会调用（实际上是Scheduler调用）job.execute方法了。

scheduler.start();
千万别忘了加上上面的语句，这条语句通知Quartz使安排的计划生效。

关于execute方法的参数JobExecutionContext
JobExecutionContext就和很多Context结尾的类功能一样，提供的运行时刻的上下文环境，JobExecutionContext中有Scheduler,JobDetail,Trigger等很多对象的引用，从而当你在execute方法内部须需要这些对象的时刻提供的便利。

在项目中，我们把需要执行的 Job 相对应的一些信息放在 JobExecutionContext 中，在 Job 执行的时候可以调用。

jobDetail.getJobDataMap().put(userid, id);

在 Job 中，我们可以拿到相关的 Context 信息：

jobExecutionContext.getJobDetail().getJobDataMap().getInt(userid);

JobDetail和Trigger的name和group
Scheduler实例对应了很多job和trigger的实例，为了方便的区分，Quartz使用name和group这两个特性，正如你想向的一样，同一个group下不能有两个相同name的JobDetail，Trigger同理，同一个Scheduler下不能有两个相同group的JobDetail,Trigger同理，JobDetail和Trigger的完全限定名为：group + name

为了让服务器重启以后，我们的 Scheduler 信息仍然不丢失，我们通常采用数据库持久化 Scheduler 的信息。
DBScript 在 Quartz 的下载包中的：quartz-1.6.0\docs\dbTables 下，选择自己使用的 DB 相应的 Script 导入数据库就可以了。
在应用中，我们需要配置一个 quartz.properties 才能正常使用 DB。我们可以在 quartz-1.6.0\examples\example10 中找到该文件的样例，稍作一些修改，就可以放到自己项目源码的根目录下使用了。

设置 org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX 即可启用基于 JDBC 的 Quartz 信息持久化。

根据项目情况设置以下配置信息：
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.dataSource = myDS
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.isClustered = false

org.quartz.dataSource.myDS.driver = com.mysql.jdbc.Driver
org.quartz.dataSource.myDS.URL = jdbc:mysql://localhost:3306/myapplication
org.quartz.dataSource.myDS.user = root
org.quartz.dataSource.myDS.password =
org.quartz.dataSource.myDS.maxConnections = 5

但是光设置了 Database 不够，我们还需要在 Application 启动的时候自动启动 Scheduler 才行，我们只需要简单的写一个 Servlet 的 Listener 并在 web.xml 中声明该 Listener ，在 Servlet 容易启动的时候，Scheduler 就开始自动执行。

public class ScheduleStartListener implements ServletContextListener {
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        try {
           scheduleFactory.getScheduler().start();
        } catch (SchedulerException e) {
           // write log
        }
    }

    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        try {
           scheduleFactory.getScheduler().shutdown();
        } catch (SchedulerException e) {
           // write log
        }
    }
}

在 web.xml 里面加入以下配置：
<listener>
    <listener-class>org.agilejava.scheduler.ScheduleStartListener</listener-class>
</listener>

以上简单的记录了在项目中关于 Quartz 的一些应用，如果有什么新的使用心得，会在后面继续加入的。