songry的专栏

activiti的配置文件主体类是Configuration，它的源码分成几部分，首先是类属性：  //日志初始化  private static Logger log = Logger.getLogger(Configuration.class.getName());  //定义通用的常量，用于各项初始化  public static final String NAME_COMMANDEXECUTOR = "CommandExecutor";  public static final String NAM

从activiti的example开始，example中所有的测试类都继承了ActivitiTestCase，顾名思义，ActivitiTestCase明显是对环节进行初始化的基类，然后看到ActivitiTestCase继承了ProcessEngineTestCase，在ProcessEngineTestCase之中，对引擎进行了初始化。那么，首先，让我们来看看ProcessEngineTestCase是怎样进行初始化的，籍此追溯到activiti的源码中去。public class ProcessEng

TestResult担任发布者角色，拥有protected List fListeners;担任观察者角色以下都是TestResult类源码/**  * Registers a TestListener观察者注册  */ public synchronized void addListener(TestListener listener) {  fListeners.add(listene

找到textui/TestRunner.java，看到了阔别很久的main方法，OK，开始运行测试。TestRunner.java/**  * 运行自身的start方法，并将返回结果提交给容器  */public static void main(String args[]) {  TestRunner aTestRunner= new TestRunner();  try {  

TestCase中实例化了TestResult，并将自身化为参数调用TestResult的run方法 TestCase.java/**  * Creates a default TestResult object  * 生成TestResult实例，单独开方法的原因我猜是有可能使用者自己继承或者实现TestCase和TestResult，  * 那么直接重写这个方法就行了  * @

众所周知，从以前的jbpm到现今的activiti，流程引擎的内部执行模式是command模式，不管是启动流程，还是推动流程等等，都采用了command的execute方法。而command执行依赖于CommandContext，直译就是command的上下文，那么，我们就来看看CommandContext里面的内容。首先是CommandContext本身的类变量和实例变量： private static Logger log = Logger.getLogger(CommandContext.class.